They are libs for builds. What libs are using tools ? Ldd ?
/usr/lib/libgcc_s.so.1 -> ??? I know about using libs by GCC, but how to fix dependencies ? And how to fix tool for using another GCC libs ? I have problem what I said about GCC4. Changing location for libs - it is big problems for tools with RPATH. -Igor On 11/14/11 2:05 PM, "Igor Pashev" <pashev.i...@gmail.com> wrote: ># ls -lh /usr/lib/gcc/x86_64-linux-gnu/4.5/libgcc_s.so >lrwxrwxrwx 1 root root 35 Сен 17 08:41 >/usr/lib/gcc/x86_64-linux-gnu/4.5/libgcc_s.so -> >/lib/x86_64-linux-gnu/libgcc_s.so.1 > ># ls -lh /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so >lrwxrwxrwx 1 root root 35 Окт 10 22:41 >/usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so -> >/lib/x86_64-linux-gnu/libgcc_s.so.1 > > >14.11.2011 13:43, Igor Kozhukhov пишет: >> 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"<richl...@richlowe.net> wrote: >> >>> On Sat, Nov 12, 2011 at 12:11, Igor Kozhukhov<ikozhuk...@gmail.com> >>> 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 >>> oi-dev@openindiana.org >>> http://openindiana.org/mailman/listinfo/oi-dev >> >> >> >> _______________________________________________ >> oi-dev mailing list >> oi-dev@openindiana.org >> http://openindiana.org/mailman/listinfo/oi-dev > > >_______________________________________________ >oi-dev mailing list >oi-dev@openindiana.org >http://openindiana.org/mailman/listinfo/oi-dev _______________________________________________ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev