This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH RFA: Build system: Check for -static-libstdc++


On 03/11/2010 18:54, Ian Lance Taylor wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:

>> How can you avoid:
>>
>> [hjl@gnu-6 gcc]$ ldd cc1
>> 	linux-vdso.so.1 =>  (0x00007ffff7ffe000)
>> 	libcloog.so.0 => /usr/lib64/libcloog.so.0 (0x0000003f22a00000)
>> 	libppl_c.so.2 => /usr/lib64/libppl_c.so.2 (0x0000003f22400000)
>> 	libppl.so.7 => /usr/lib64/libppl.so.7 (0x0000003f22000000)
>> 	libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x0000003f21c00000)
>> 	libmpc.so.2 => /usr/lib64/libmpc.so.2 (0x00007ffff7dcd000)
>> 	libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x00007ffff7b7e000)
>> 	libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x0000003f2b400000)
>> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007ffff797a000)
>> 	libz.so.1 => /lib64/libz.so.1 (0x00007ffff7764000)
>> 	libc.so.6 => /lib64/libc.so.6 (0x0000003f21400000)
>> 	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003f2d000000)
>> 	libm.so.6 => /lib64/libm.so.6 (0x0000003f21800000)
>> 	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003f2bc00000)
>> 	/lib64/ld-linux-x86-64.so.2 (0x0000003f21000000)
>> [hjl@gnu-6 gcc]$
>>
>> Please note:
>>
>> 1. GCC is still in C.
>> 2. libstdc++.so.6 dependency comes from other DSOes.
> 
> That case is different.  The libstdc++.so there is not the one from the
> bootstrapped compiler.  It is the system one, brought in from the
> dependencies of the other shared libraries.  This causes no unusual
> difficulty.

  Yes, but what about the _usual_ difficulties of having two independent
copies of a library linked into the same executable?  We may not be using
new/delete or throwing exceptions in the compiler just yet, but it still looks
really like an accident waiting to happen to me.

  For example: suppose there's a pair of functions in gmpxx or ppl or cloog,
called from the middle-end of the go1 executable, that allocate and deallocate
some object or other; suppose the allocate function is an extern, prototyped
in the related lib's header file, but the deallocator is inline; go1 calls the
allocater, which invokes the system libstdc DSO's operator new; then go1 calls
the deallocater, which gets inlined, and ends up invoking the
statically-linked libstdc's operator delete.  Couldn't that happen?

    cheers,
      DaveK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]