Re: Failed installing GNUstep-GUI on Debian Squeeze using SVN

[Csanyi Pal]

Fred Kiefer <fredkiefer@gmx.de> writes:

> On 21.03.2011 20:55, Csanyi Pal wrote:
>> Fred Kiefer<fredkiefer@gmx.de>  writes:
>>
>>> On 21.03.2011 20:23, Csanyi Pal wrote:
>>>>
>>>> I have installed follows:
>>>>
>>>> $ aptitude show libxml2
>>>> Package: libxml2
>>>> State: installed
>>>> Automatically installed: no
>>>> Version: 2.7.8.dfsg-2
>>>> Priority: standard
>>>> Section: libs
>>>> Maintainer: Debian XML/SGML Group
>>>> <debian-xml-sgml-pkgs@lists.alioth.debian.org>
>>>> Uncompressed Size: 1745 k
>>>> Depends: libc6 (>= 2.7), zlib1g (>= 1:1.2.3.3.dfsg)
>>>>
>>>> $ aptitude show zlib1g
>>>> Package: zlib1g
>>>> State: installed
>>>> Automatically installed: no
>>>> Version: 1:1.2.3.4.dfsg-3
>>>> Priority: required
>>>> Section: libs
>>>> Maintainer: Mark Brown<broonie@debian.org>
>>>> Uncompressed Size: 176 k
>>>> Depends: libc6 (>= 2.2.5)
>>>>
>>>> I configured and builded base again and run 'make check' with results:
>>>> 5543 Passed tests
>>>>     11 Dashed hopes
>>>>     10 Skipped sets
>>>>      4 Failed builds
>>>>      1 Failed test
>>>>
>>>> After that I try to configure and build and install gui but still get
>>>> errors:
>>>>
>>>> Making all in Tools ...
>>>> Making all for tool make_services...
>>>>    Linking tool make_services ...
>>>> /usr/lib64/libxml2.so.2: undefined reference to `gzopen64'
>>>> /usr/lib64/libxml2.so.2: undefined reference to `gzdirect@ZLIB_1.2.2.3'
>>>> /usr/local/lib/libgnustep-base.so: undefined reference to `gzseek64'
>>>> collect2: ld returned 1 exit status
>>>> make[4]: *** [obj/make_services] Error 1
>>>> make[3]: *** [internal-tool-all_] Error 2
>>>> make[2]: *** [make_services.all.tool.variables] Error 2
>>>> make[1]: *** [internal-all] Error 2
>>>>
>>>> Any advices to go further?
>>>
>>> No new advise, but I would like to reiterate Richards comment to check
>>> for the developer package of zlib1g. You only listed the normal
>>> packages both for libxml2 and zlib1g. To compile GNUstep base with
>>> full features you will also need the corresponding development
>>> packages which contain the headers and the link stubs for the
>>> libraries.
>>> The next thing you should check is to run ldd on the GNUstep base
>>> library. In my case the command is:
>>> ldd /usr/GNUstep/System/Library/Libraries/libgnustep-base.so
>>
>> I find that that in my case this command is:
>> $ ldd /usr/GNUstep/Local/Library/Libraries/libgnustep-base.so
>>
>>> Please report back the results. If zlib doesn't show up in that list
>>> we need to find out why. For this we will need the configure log file
>>> for base.
>>
>> linux-vdso.so.1 =>   (0x00007fffc4db5000)
>> libpthread.so.0 =>  /lib/libpthread.so.0 (0x00007f952b244000)
>> libobjc.so.2 =>  /usr/lib/libobjc.so.2 (0x00007f952b028000)
>> libxml2.so.2 =>  /usr/lib/libxml2.so.2 (0x00007f952acd7000)
>> libffi.so.5 =>  /usr/lib/libffi.so.5 (0x00007f952aacf000)
>> libnsl.so.1 =>  /lib/libnsl.so.1 (0x00007f952a8b7000)
>> librt.so.1 =>  /lib/librt.so.1 (0x00007f952a6ae000)
>> libdl.so.2 =>  /lib/libdl.so.2 (0x00007f952a4aa000)
>> libz.so.1 =>  /usr/lib/libz.so.1 (0x00007f952a293000)
>> libm.so.6 =>  /lib/libm.so.6 (0x00007f952a010000)
>> libgcc_s.so.1 =>  /lib/libgcc_s.so.1 (0x00007f9529dfa000)
>> libc.so.6 =>  /lib/libc.so.6 (0x00007f9529a99000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007f952bba2000)
>
> OK, so now it is me who is confused. In your error message we find the
> line /usr/lib64/libxml2.so.2 which clearly states that the 64 bit of
> the libxml2 gets loaded. Now the ldd dump seems to imply that the 32
> bit version of this library was linked against GNUstep. And if the
> file at /usr/lib/libxml2.so.2 is just a link to the 64 bit version at
> /usr/lib64/libxml2.so.2, is the same true for the file
> /usr/lib/libz.so.1?
> I would say, that the version of libxml2 found in /usr/lib64 is just
> the wrong one and you will have to do away with that to get this issue
> resolved.

The files:
/usr/lib64/libxml2.so
/usr/lib64/libxml2.so.2 
are symlinks to the  libxml2.so.2.7.8  which is:
/usr/lib64/libxml2.so.2.7.8: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, stripped 

and the files:
/usr/lib64/libz.so
/usr/lib64/libz.so.1
are symlinks to the  libz.so.1.2.3.4  which is:
/usr/lib64/libz.so.1.2.3.4: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, stripped 

I have installed libxml2 using aptitude on Debian Squeeze but that not
mean that it must be the right one, right?

> Also please have a look at this Debian bug report:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526131

I have run the command:
# ldd /usr/lib/libxml2.so.2
 linux-vdso.so.1 =>  (0x00007fff7aaea000)
 libdl.so.2 => /lib/libdl.so.2 (0x00007fdf8988b000)
 libz.so.1 => /usr/lib/libz.so.1 (0x00007fdf89674000)
 libm.so.6 => /lib/libm.so.6 (0x00007fdf893f1000)
 libc.so.6 => /lib/libc.so.6 (0x00007fdf89090000)
 /lib64/ld-linux-x86-64.so.2 (0x00007fdf89df8000)

where the /usr/lib/ directory is actually the /usr/lib64/ directory
because in /usr/ directory the lib64/ is a symlink to lib/

> the wrong one and you will have to do away with that to get this issue
> resolved.

How can I do away with that?

-- 
Regards, Paul
<http://sourceforge.net/projects/lptinterface/>
<http://savannah.nongnu.org/projects/lpt-interface/>
<http://csanyi-pal.info>