On Sat, Apr 04, 2009 at 04:25:21PM +0100, Victor Churchill wrote:
> I've downloaded Oracle's 64 bit release 10gR2 : the download filename
> was 10201_database_linux_x86_64.cpio.gz.
> However, Oracle only certify this for Red Hat and Suse, not Debian or Ubuntu.
> 
> By following the usual link-from-a-link-from-a-forum process I have
> got a good way into the install and am now encountering an error which
> seems related to a 32/64 bit lib compatibility issue.
> 
> Log file shows:
> 
>  gcc -m32 -o ctxhx -L/u01/app/oracle/product/10.2.0/db_1/ctx/lib32/
> -L/u01/app/oracle/product/10.2.0/db_1/lib32/
> -L/u01/app/oracle/product/10.2.0/db_1/lib32/stubs/
> /u01/app/oracle/product/10.2.0/db_1/ctx/lib/ctxhx.o
> -L/u01/app/oracle/product/10.2.0/db_1/ctx/lib/ -ldl -lm -lctxhx
> -Wl,-rpath,/u01/app/oracle/product/10.2.0/db_1/ctx/lib -lsnls10
> -lnls10  -lcore10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lxml10
> -lcore10 -lunls10 -lsnls10 -lnls10 -lcore10 -lnls10  `cat
> /u01/app/oracle/product/10.2.0/db_1/lib/sysliblist`
> 
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../libpthread.so when
> searching for -lpthread
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../libpthread.a when
> searching for -lpthread
> /usr/bin/ld: skipping incompatible /usr/bin/../lib/libpthread.so when
> searching for -lpthread
> /usr/bin/ld: skipping incompatible /usr/bin/../lib/libpthread.a when
> searching for -lpthread
> /usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when
> searching for -lpthread
> /usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when
> searching for -lpthread
> /usr/bin/ld: cannot find -lpthread
> collect2: ld returned 1 exit status

   It's only searching /usr/lib/-style directories. On a 64-bit
machine, those are likely to be 64 bit. The incompatibility it's
complaining about is from ld, which knows that it's building for a
32-bit architecture (why? is the original code not 64-bit clean?), and
so is throwing out the 64-bit libs it's finding on the search path.

   One nasty option is to try hacking -L/lib32 into the makefile for
that particular command, and see what it does.

   Another alternative might be to try running that particular bit of
the build through the "linux32" wrapper, as that should give it a
32-bit-like environment to run in.

   My limited experience of building 32-bit stuff on a 64-bit platform
hasn't been terribly good, and generally comes down to "run it in a
linux32-wrapped chroot of a 32-bit install of the OS", or "run it in a
32-bit VM", which are much the same thing at this level.

> Now part of the precursor steps involved various apt-get installs of
> lib packages including 32 bit compatibility ones such as sudo apt-get
> install ia32-libs .
> 
> I have looked into my libs for libpthread  and found
> 
> q...@pe2950:~$ file /lib*/libpthread*
> /lib32/libpthread-2.7.so: ELF 32-bit LSB shared object, Intel 80386,
> version 1 (SYSV), for GNU/Linux 2.6.8, not stripped
> /lib32/libpthread.so.0:   symbolic link to `libpthread-2.7.so'
> /lib64/libpthread-2.7.so: ELF 64-bit LSB shared object, x86-64,
> version 1 (SYSV), for GNU/Linux 2.6.8, not stripped
> /lib64/libpthread.so.0:   symbolic link to `libpthread-2.7.so'
> /lib/libpthread-2.7.so:   ELF 64-bit LSB shared object, x86-64,
> version 1 (SYSV), for GNU/Linux 2.6.8, not stripped
> /lib/libpthread.so.0:     symbolic link to `libpthread-2.7.so'
> 
> 
> I thought perhaps the buiid was wanting a 32 bit library at that point
> in the compilation, but
> If I try to replace the target of /lib/libpthread.so.0 with the 32 bit 
> version:
> 
> q...@pe2950:/lib$ sudo mv libpthread.so.0 _64bit_libpthread.so.0
> q...@pe2950:/lib$ sudo ln -s /lib32/libpthread-2.7.so libpthread.so.0
> 
> then the make fails differently -
> 
> INFO: /usr/bin/make: error while loading shared libraries:
> libpthread.so.0: wrong ELF class: ELFCLASS32
> 
> So that's not what the 'incompatible' is about.

   I suspect that that's *make* failing to start, as it's trying to
load the thread libs and having problems. So it might actually be a
viable solution to your build problem -- except that the build
tools themselves won't work if you do that. :(

   Hugo.

-- 
=== Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
    --- All mushrooms are edible,  but some are only edible once. ---    

Attachment: signature.asc
Description: Digital signature

-- 
Please post to: Hampshire@mailman.lug.org.uk
Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire
LUG URL: http://www.hantslug.org.uk
--------------------------------------------------------------

Reply via email to