Fred Kiefer <[email protected]> writes: > On 21.03.2011 20:55, Csanyi Pal wrote: >> Fred Kiefer<[email protected]> 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 >>>> <[email protected]> >>>> 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<[email protected]> >>>> 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> _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
