2009/4/4 Hugo Mills <h...@carfax.org.uk>: > On Sat, Apr 04, 2009 at 04:25:21PM +0100, Victor Churchill wrote: >> >> 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?),
presumably not... > 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. Interestingly, after sending the OP I looked at: ora...@pe2950:~/install/database$ echo $LD_LIBRARY_PATH /usr/lib So I then said ora...@pe2950:~/install/database$ export LD_LIBRARY_PATH="/lib32:/usr/lib32:$LD_LIBRARY_PATH" and then re-ran the installer, but no difference in the result. (Not even in the list of "/usr/bin/ld: skipping incompatible" lines, which surprised me). I am trying to find the line in the make file that corresponds to this gcc line but that is itself quite hard. Does not seem to be quite where I thought, but it is of course all $(PARAMETER)ised. > > 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. ... so I shall give that a go! (Hadn't come across that... thank you.) > > 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. I guess we could end up doing that, even. <snip> >> 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. :( Now /that/ made me think for 30 seconds and then ... well, my keyboard needed a clean anyway ;-) -- 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 --------------------------------------------------------------
