Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 243874 - dev-lang/icon: CC variable not respected
Summary: dev-lang/icon: CC variable not respected
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Maintainers for Miscelleneous Language Packages [OBSOLETE]
Depends on: 274174
Blocks: tc-directly
  Show dependency tree
Reported: 2008-10-24 17:30 UTC by Diego Elio Pettenò (RETIRED)
Modified: 2009-11-15 11:46 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò (RETIRED) gentoo-dev 2008-10-24 17:30:28 UTC
I'm filing this bug (from a template, mind you) because the ebuild I'm reporting it against failed to build once I removed my /usr/bin/{gcc,cc,c++,c99} binaries. This means that the ebuild is relying on gcc or cc as compiler, while it should use "$(tc-getCC)" so that user choices are respected, and cross-compiling works as intended.

This usually comes down to one of these tasks:

- use emake CC="$(tc-getCC)" for building, to ovewrite make's CC variable (defaults to "cc", some upstream rewrites it);
- the above plus replacing explicit "gcc" (or similar) calls with $(CC) so that the variable is actually respected;
- tc-export CC in src_compile before eventual econf.

For C++, you'd have to replace CC with CXX everywhere above, of course.

If your package is a special case on this, please let me know.

Comment 1 Cheyenne Wills 2008-11-06 15:49:51 UTC
Compiling Icon using a different compiler other then GCC under Linux might not work. In the past, Icon has "broken" C compilers (the compilers do not generate the correct code).  There is some code that is sensitive to the C stack frame layout (though there is now an alternative that uses a more portable, though slower method).

The problem is not in the ebuild, but in the build configurations used by Icon itself.  You will have to create and test a new configuration (basically "porting" Icon to the new compiler).

If you would like to try as test, Icon does have a fairly decent test suite.  If the test suite "works" then I would say that the C compiler was good enough.

Doing a test build is fairly simple:

o extract the tar file in some local temp directory
o make X-Configure name=linux
o Update the file Makedefs to point to the compiler and options you want
o cross your fingers...
o make All
o make Test

Examine the results of the Test and determine if any "errors" are okay. 

When I was heavily involved with porting Icon to different platforms, I would routinely find bugs in the C compilers that I was using (to the point that one compiler manufacture started using me as an alpha tester).  I also know of one C compiler manufacture that uses (or at least used) Icon as part of their test suite for their C compiler.
Comment 2 Cheyenne Wills 2008-11-06 15:53:30 UTC
Oh.. as one possible "solution" is to update the ebuild to do a hard depend on gcc. (though it doesn't help with the cross-compiling issue).
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2008-11-06 16:10:41 UTC
This has nothing to do with not using GCC, it has to do with using the right name for GCC ($CHOST-gcc rather than just gcc) and to respect eventual settings for ccache/distcc.
Comment 4 Cheyenne Wills 2008-11-06 16:26:13 UTC
(In reply to comment #3)
> This has nothing to do with not using GCC, it has to do with using the right
> name for GCC ($CHOST-gcc rather than just gcc) and to respect eventual settings
> for ccache/distcc.

The GCC compiler is "named" in the file Makedefs - which is built (actually copied from the config/{configname}/Makedefs directory.  

So.. the "patch" to the ebuild might be right after the emake X-Configure .. to then modify the Makedefs file.

However I just noticed that the current icon-9.4.3-r4.ebuild has been updated to override the CC, CFLAGS and LDFLAGS.  If this is the case, then I would *strongly* suggest that the a emake Test always be performed after the emake All to ensure that the new configuration works.

Comment 5 Harald van Dijk (RETIRED) gentoo-dev 2009-11-15 11:46:41 UTC
This should've been closed a long time ago.