rpms/inkscape/devel inkscape-0.42-GC-check.patch, 1.1, 1.2 inkscape.spec, 1.20, 1.21

[Rex Dieter]

Rex Dieter wrote:
> Rex Dieter wrote:
> 
>> Michael Schwendt wrote:
>>
>>> On Fri, 19 Aug 2005 08:21:32 -0500, Rex Dieter wrote:
>>
>>
>>
>>>> FYI, Extras gc is patched (gc*opendl.patch) to not need -lpthread 
>>>> -ldl (it's linked in the shared lib so there are no undefinted 
>>>> symbols, and help prelink), so you could probably leave those out 
>>>> altogether, if you're already testing things.
>>>
>>>
>>>
>>>
>>> Well, I didn't patch it without reason. Inkscape gtk/cairo rebuild 
>>> request
>>> failed after 10 seconds on x86_64, which made me insert "cat config.log"
>>> to get a better picture:
>>
>>
>> ...
>>
>>> configure: error: libgc (the Boehm Conservative Collector) 6.4+, is 
>>> needed to compile inkscape -- 
>>> http://www.hpl.hp.com/personal/Hans_Boehm/gc
>>> + :
>>> + cat config.log
>>> [...]
>>> configure:22935: checking for GC_init in -lgc
>>> configure:22965: g++ -o conftest -O2 -g -pipe -Wall 
>>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
>>> --param=ssp-buffer-size=4 -m64 -mtune=nocona   conftest.cc -lgc   >&5
>>> /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../lib64/libgc.so: 
>>> undefined reference to `pthread_create'
>>> /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../lib64/libgc.so: 
>>> undefined reference to `dlopen'
>>
>>
>>
>> WTF?  On my FC4 system at least (with gc-6.5):
>>
>> $ldd /usr/lib/libgc.so
>>         linux-gate.so.1 =>  (0x001f2000)
>>         libpthread.so.0 => /lib/libpthread.so.0 (0x00e8d000)
>>         libdl.so.2 => /lib/libdl.so.2 (0x00977000)
>>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x004b5000)
>>         libc.so.6 => /lib/libc.so.6 (0x006ca000)
>>         /lib/ld-linux.so.2 (0x00433000)
>>
>> (Not sure what linux-gate.so.1 is??)
>>
>> I'll have to go check on FC5(devel) to see if libgc really did link 
>> against libdl/libpthread or not.
>>
>> Is this failure specific to x86_64 or does it occur on i386 too?
> 
> 
> I've confirmed the failure to be specific to x86_64.  That build isn't 
> linked against libdl/libpthread.  Now, I need to determine why/how it 
> happened.

 From gc's x86_64 build.log:  No shared -lpthread or -ldl on x86_64?
Anyone know what's going on here?


------------------------


/bin/sh ./libtool --mode=link gcc -fexceptions -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffe
r-size=4 -m64 -mtune=nocona  -o libgc.la -rpath /usr/lib64 -version-info
1:2:0 allchblk.lo alloc.lo blacklst.lo checksums.lo dbg_mlc.lo dy
n_load.lo finalize.lo gc_dlopen.lo gcj_mlc.lo headers.lo malloc.lo
mallocx.lo mark.lo mark_rts.lo misc.lo new_hblk.lo obj_map.lo os_dep.lo
  pcr_interface.lo ptr_chck.lo real_malloc.lo reclaim.lo
solaris_pthreads.lo solaris_threads.lo specific.lo stubborn.lo
typd_mlc.lo backgra
ph.lo win32_threads.lo pthread_support.lo pthread_stop_world.lo
darwin_stop_world.lo  mach_dep.lo -lpthread -ldl
mkdir .libs
rm -fr .libs/libgc.la .libs/libgc.* .libs/libgc.*

*** Warning: This library needs some functionality provided by -lpthread.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by -ldl.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.