[oi-dev] oi-build feature #1252 - GCC 4.6.2

[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.

-Igor


On 11/14/11 2:05 PM, "Igor Pashev" <pashev.igor at 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"<richlowe at richlowe.net>  wrote:
>>
>>> On Sat, Nov 12, 2011 at 12:11, Igor Kozhukhov<ikozhukhov at 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 at openindiana.org
>>> http://openindiana.org/mailman/listinfo/oi-dev
>>
>>
>>
>> _______________________________________________
>> oi-dev mailing list
>> oi-dev at openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
>
>
>_______________________________________________
>oi-dev mailing list
>oi-dev at openindiana.org
>http://openindiana.org/mailman/listinfo/oi-dev