Project

General

Profile

Bug #920

Cross compiling for Android on OSX is keep using '/usr/bin/gcc'

Added by Tao Wang about 8 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
build
Target version:
Start date:
22 Sep 2013
Due date:
% Done:

100%

Estimated time:

Description

To cross compile the exiv2 for Android, the standalone toolchain created by Android NDK should be used. However, although CC and CXX has been set to the standalone toolchain, it keeps using system's '/usr/bin/gcc' and '/usr/bin/g++'.

After check the CMakeLists.txt, I found the following lines:
--------- ##
  1. Issue:#857. Use g++ instead of c++ (clang) compiler to eliminate warnings
    if (APPLE)
    set(CMAKE_C_COMPILER gcc)
    set(CMAKE_CXX_COMPILER g++)
    endif(APPLE) ##
    ---------

This code fixed issue 857. However, it should only force to use 'gcc' when the target is the host.


Related issues

Related to Exiv2 - Bug #857: CMake compilation issue on MacOS-X 4.5.1/Mountain LionClosed07 Oct 2012

Actions
Related to Exiv2 - Bug #1131: Please explain the RCSID macro at the start of every .cpp file.Closed25 Oct 2015

Actions

History

#1

Updated by Robin Mills about 8 years ago

Tao

Thanks for reporting this. Good detective work. Well done.

I don't have the Android SDK on my machines (and have never used the Android SDK on any platform).

I think you are saying that you are using a Mac to cross build for Android. The IF statement here requires a modification. If you know how to modify this, please let me know and I will submit a fix.

As a work-around, you may be able to force the tool-chain from the make command line using

 $ make CXX=<path> CC=<path> 

Another obvious work-around is to use Windows or Linux to cross compile.

Robin

#2

Updated by Gilles Caulier about 8 years ago

Robin,

I don't know who has written this condition here, but it's not me.

Using g++ instead of c++ (clang) compiler to eliminate warnings under OSX is typically a bad idea. Not because GCC is wrong, it's not the case. But ignoring warnings from a compiler is typically a wrong way. Warnings must be fixed in fact.

Also Clang will be verbose differently than GCC. It's a good point for developers to know a possible mess in source code. MSVC is different also under Windows, and very instructive. Typically, i already important bug that GCC don't see using another compiler.

I recommend to drop this rules definitively. As CLang use similar options than GCC, you can just do this rule with cmake to suppress warnings at compilation time :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/entry/digikam/CMakeLists.txt?rev=development%2F3.0.0#L7

Gilles Caulier

#3

Updated by Robin Mills about 8 years ago

I agree with you about warnings from the compiler. There are a number of issues related to clang. http://dev.exiv2.org/issues/857

There is a warning on every C++ file being issued by clang in response to statements such as:

EXIV2_RCSID("@(#) $Id: exiv2.cpp 3118 2013-08-13 06:28:46Z nhudinhtuan $")

I haven't really understood what this code does, however it has something to do with the linker. It is documented in a man page (however I can't remember where). Anyway it is discussed on this topic: http://dev.exiv2.org/issues/857

I agree, I have not solved this issue correctly and for that reason, I deferred it to 0.25 during my bug review for 0.24. You'll notice that Andreas said (in 857) Sooner or later someone will tell us what's really wrong. Now's the time, Gilles. Do you know how to fix the ident code on clang?

It is my error to have added the IF code to suppress the clang warning. My error. I am guilty!

Robin

#4

Updated by Robin Mills about 8 years ago

  • Status changed from New to Assigned
  • Assignee set to Robin Mills

Fix submitted: r3172.

#5

Updated by Robin Mills about 8 years ago

  • Status changed from Assigned to Resolved
  • Target version changed from 0.24 to 0.25
  • % Done changed from 0 to 100

I'm going to mark this as "resolved". If anybody disagrees with my fix, please update this issue report with your concerns. If the fix is not contested, the issue will be closed during bug review for the 0.25 release.

#6

Updated by Andreas Huggel over 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF