[gentoo-amd64] Re: Curious thing- linking against .so libs...

[gentoo-amd64] Re: Curious thing- linking against .so libs...

[Nikos Chantziaras]

Branko Badrljica wrote:
> gcc -O2 -m32 -march=barcelona -pipe -L/usr/lib64 -lgdgeda -o tt tt.c 
> (libgdgeda has just .so )

-m32 generates 32-bit code.  /usr/lib64 is only for 64-bit binaries. 
Don't use -m32.

[gentoo-amd64] Curious thing- linking against .so libs...

[Branko Badrljica]

I was trying to install nVidia's CUDA SDK for toying with GPU as 
computing tool, but I soon found out that I can't compile anything.

I always get error's like "can't find -lGL" etc from compiler. So I took 
a look where LIBPATHetc were set and everything seemed fine.

After that, I tried with trivial "Hello world" test source. I tried to 
compile it, linking it with libGL.so. Compile failed with familiar 
"can't find...".

Then I tried to link it to another libraries I found in /usr/lib64. It 
turns out that gcc wants to link to .a/.la files and completely seems to 
ignore .so.

What gives ?

I have standard Gentoo config on Phenom system with typical desktop 
setup. gcc is v-4.3.2.

Test case program:

#include <stdio.h>

void main ( int argc , char ** argv )   {
        printf("Argc is %d, arg zero is %s and arg one is %s\n" , argc, 
argv[0] , argv[1] );
};


Compile attempts that work fine:

gcc -O2 -m32 -march=barcelona -pipe -o tt tt.c


gcc -O2 -m32 -march=barcelona -pipe -L/usr/lib64 -lresolv -o tt tt.c ( 
resolv lib has .la and .so version )

One that fails:

gcc -O2 -m32 -march=barcelona -pipe -L/usr/lib64 -lgdgeda -o tt tt.c 
(libgdgeda has just .so )


Any ideas ?

[gentoo-amd64] Re: Curious thing- linking against .so libs...

[Duncan]

Nikos Chantziaras <realnc@arcor.de> posted ghnsoh$ubf$1@ger.gmane.org,
excerpted below, on  Wed, 10 Dec 2008 09:57:08 +0200:

> Branko Badrljica wrote:
>> gcc -O2 -m32 -march=barcelona -pipe -L/usr/lib64 -lgdgeda -o tt tt.c
>> (libgdgeda has just .so )
> 
> -m32 generates 32-bit code.  /usr/lib64 is only for 64-bit binaries.
> Don't use -m32.

That's absolutely correct as far as it goes, but may miss the point.

Presumably, the OP is trying to compile 32-bit code, thus the -m32.  Does 
that nVidia stuff even support 64-bit?  If he's trying to do 64-bit 
compiles, then you are right, kill that -m32.  If he's trying to do 32-
bit compiles, he must link to 32-bit libs, not the 64-bit libs he's 
trying to link to at present.

Keep in mind that Gentoo's 32-bit side of multilib is rather limited.  In 
general, it's designed to work with pre-built binaries, not for compiling 
32-bit, altho trivial 32-bit programs only using glibc and (for C++) 
libstdc++ (part of gcc) should be compilable.

If you're going to be doing a lot of 32-bit compilation, the suggested 
solution is to use a 32-bit chroot in which you start from a standard 32-
bit stage tarball and build most of an entire 32-bit Gentoo installation 
(sans kernel and services that are provided by the 64-bit side).  It 
works and is in some ways much more in keeping with the normal Gentoo 
build-from-sources spirit, but it's a LOT more work than just running a 
standard multilib system so you can run the occasional 32-bit-only 
binary. 

Here's the Gentoo/amd64 32-bit chroot HOWTO:
http://www.gentoo.org/proj/en/base/amd64/howtos/chroot.xml

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Curious thing- linking against .so libs...

[Branko Badrljica]

Nikos Chantziaras wrote:
> Branko Badrljica wrote:
>> gcc -O2 -m32 -march=barcelona -pipe -L/usr/lib64 -lgdgeda -o tt tt.c 
>> (libgdgeda has just .so )
>
> -m32 generates 32-bit code.  /usr/lib64 is only for 64-bit binaries. 
> Don't use -m32.
>

Sorry, I forgot to remove -m32 from my example- it was remnant from 
previous tries.
Everything is the same without it.

But it seems something else is broken on my system, so I'll recompile 
everything and report later...