Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
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
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
# 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 Lowerichl...@richlowe.net wrote: On Sat, Nov 12, 2011 at 12:11, Igor Kozhukhovikozhuk...@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
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
# dpkg -S libgcc_s lib32gcc1: /usr/lib32/libgcc_s.so.1 gcc-4.5: /usr/lib/gcc/x86_64-linux-gnu/4.5/libgcc_s.so libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 gcc-4.6: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so 14.11.2011 14:16, Igor Kozhukhov пишет: 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. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
I can see one real file: libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 And 2 different symlinks to this file: gcc-4.5: /usr/lib/gcc/x86_64-linux-gnu/4.5/libgcc_s.so gcc-4.6: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so It is not correct if wee have different libs. And you didn't provide LDD output for some tools. -Igor On 11/14/11 3:01 PM, Igor Pashev pashev.i...@gmail.com wrote: # dpkg -S libgcc_s lib32gcc1: /usr/lib32/libgcc_s.so.1 gcc-4.5: /usr/lib/gcc/x86_64-linux-gnu/4.5/libgcc_s.so libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 gcc-4.6: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so 14.11.2011 14:16, Igor Kozhukhov пишет: 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. ___ 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
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
14.11.2011 15:12, Igor Kozhukhov пишет: I can see one real file: libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 Try to guess what ldd will show ;-) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
On Mon, Nov 14, 2011 at 04:43, Igor Kozhukhov ikozhuk...@gmail.com wrote: 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. GCC attempt to maintain backward compatibility in their runtime libraries. This should not be a problem, and we're in the process of actually testing whether this _is_ a problem, sort of, via OI-SFE. -- Rich ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
On Mon, 2011-11-14 at 20:04 -0500, Josef 'Jeff' Sipek wrote: Keep in mind that we have mediated links - something that debian doesn't have. Is Debian exceptional as a Linux distribution in this respect? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
15.11.2011 05:04, Josef 'Jeff' Sipek пишет: On Mon, Nov 14, 2011 at 03:19:44PM +0400, Igor Pashev wrote: 14.11.2011 15:12, Igor Kozhukhov пишет: I can see one real file: libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 Try to guess what ldd will show ;-) Keep in mind that we have mediated links - something that debian doesn't have. It is not true, Debian has update-alternatives. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
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
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
On Mon, Nov 07, 2011 at 04:48:05PM +, Colin Ellis wrote: https://bitbucket.org/cellis_oidev/oi-build/changeset/170076b03654 use Makefile.bootstrap files for gcc3 :) Ooooh! So, to build it the first time, I need to 'gmake -f Makefile.bootstrap' for the libs, then gcc. Once I have them installed, I can ignore the bootstrap files? Why are there two packages - one for gcc and one for the runtime? It seems to me that using facets would be the better way. Since we have a new enough pkg in /experimental, we can use mediated links to manage /usr/bin/gcc (as well as g++, etc.). I think it'd be worth having them. Jeff. -- Failure is not an option, It comes bundled with your Microsoft product. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
