Big problems - they are GCC_LIBS. We can't use different GCC version from /usr/gcc/<version> with GCC_LIBS from one place - because we have for example: libgcc_s.so.1 and others with the same names for different GCC versions and we have to use libgcc_s.so for -lgcc_s flags for linker.
We don't have problems with tools if we are using static libs, but we have a big problems with dynamic libs - have to identify where primary libs is locate. We can put libs to different places, but it is next problem - we have to use RPATH for identification where libs locate - it is not good solution. Next problem - not critical, but present - we have package with GCC_LIBS and we have dependencies to this package in tools after builds. We have to re-build all tools after changing package name. Will be better to have ONE GCC version on the system and use it. This is example for GCC4.4 and GCC4.6 - not for GCC3 from /usr/sfw. -Igor On 11/13/11 2:06 AM, "Richard Lowe" <[email protected]> wrote: >On Sat, Nov 12, 2011 at 12:11, Igor Kozhukhov <[email protected]> >wrote: >> I think that link to /usr/bin/gcc - it as mistake, because you will >>broke >> illumos-gate build. > >The illumos build uses /usr/sfw/bin/gcc, If the build finds or tries >to use /usr/bin/gcc, something is wrong with illumos. > >> We have to save illumos-gate build based on current userland. > >That's why /usr/sfw/bin/gcc must be left alone /usr/bin/gcc should be >fine. Of course, it's probably a good idea for someone to test that. > >The patched GCC4 is not important until the changes to illumos >integrate. The intent behind the way we were structuring the GCC >paths going forward was that the need for a special GCC for illumos >does not impact any other use of GCC in the system. That is, >/usr/gcc/X.Y.Z was to be used by people who _specifically_ required a >version of GCC, such as illumos, whereas /usr/bin/gcc could be a >convenient, user-appropriate, version. > >-- Rich > >_______________________________________________ >oi-dev mailing list >[email protected] >http://openindiana.org/mailman/listinfo/oi-dev _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
