[phobos] 32 and 64 bit libraries on Linux

[Jonathan M Davis]

On Tuesday, January 04, 2011 15:18:16 Walter Bright wrote:
> The command and the barf:
> 
> gcc foo.o -o foo -m32 -Xlinker -L/home/walter/cbx/mars1/phobos -lphobos
> -lpthread -lm
> /usr/bin/ld: skipping incompatible
> /home/walter/cbx/mars1/phobos/libphobos.a when searching for -lphobos
> /usr/bin/ld: cannot find -lphobos
> collect2: ld returned 1 exit status
> --- errorlevel 1
> 
> 
> So, what to do?
> 
> 1. what to name the libraries?
> 2. where to put the libraries?
> 3. how should dmd invoke gcc to do the linking?
> 4. what goes in dmd.conf?
> 
> 1,2,3 for -m32, -m64, and the default?

I would think that the issue is that the correct libphobos.a isn't on the 
linker's path. It looks like /home/walter/cbx/mars1/phobos/libphobos.a is the 
wrong version. I believe that for -lphobos to work, the library must be named 
exactly libphobos.a, be compiled for the correct architecture, and be in the 
linker's bath. So, if you don't have a libphobos.a of the correct architecture 
on the linker's path, then the linking will fail.

If both the 32-bit and 64-bit versions are included in the linker's path, then I 
would expect the linker to select the correct one. So, if you had directories 
such as lib32 and lib64 in the distributed zip file, both of them have a 
libphobos.a of the corresponding architecture, and dmd.conf includes -L 
arguments for both directories, then the linker should find them and use the 
correct one. Then, if the user or distribution maintainer wishes to put them 
elsewhere (such as /usr/lib or /usr/lib64), then they either just move them to 
the desired location and alter dmd.conf so that the -L arguments point to 
wherever they put the libraries (or probably just remove the -L arguments if 
they put the libraries somewhere where ld already looks on their system).

So, I would think that the correct things to do would be

1. Name them both libphobos.a.

2. Put the libraries in separate directories - probably named lib32 and lib64 - 
somewhere in the zip file (you should probably just replace the current lib 
directories with a lib32 and lib64 directory).

4. Assuming that you replaced linux/lib with linux/lib32 and linux/lib64, then 
you remove -L-L%@P%/../lib from the current dmd.conf and add -L-L%@P%/../lib32 
and -L-L%@P%/../lib64. If you're compiling with -m32, the linker will use the 
32-bit version, and if you're compiling with -m64, it'll use the 64-bit version. 
Anyone who wants to put the libraries elsewhere can just edit their dmd.conf 
accordingly.

3. I'm not all that well-versed in gcc, so maybe there's some nuance I'm 
missing. But what you're doing there looks right as long as the -L flags point to 
the correct directories. Use -m32 for 32-bit builds and -m64 for 64-bit builds.

Now, I'm not quite sure how you'd deal with the default value for -m. Normally, 
I'd expect you to have a 32-bit version of dmd if you're on a 32-bit system and 
a 64-bit version of dmd if you're on a 64-bit system. Then the 32-bit version 
defaults to -m32, and the 64-bit version defaults to -m64. But as I understand 
it, you're not currently planning to do a 64-bit version of dmd.... gcc will be 
32-bit or 64-bit and therefore will default to the correct architecture if you 
don't give it a value for -m, but dmd is still going to need to know the 
architecture for the compilation phase, so you can't just skip the -m when 
linking and expect that to work. It sounds like dmd is going to need a way to 
know what architecture it's currently compiling on, or it's going to have to 
default to 32-bit (which would be less than ideal). Once it's determined the 
correct architecture, it can use that for the compilation phase, and it will 
know whether to use -m32 or -m64 in the linking phase.

I am by no means an expert on how linking and libraries work on Linux, but I 
have been using primarily 64-bit multilib Linux systems for a while, so I think 
that I have a fair grasp of the situation, and I _think_ that what I've said is 
correct, but I could be missing something vital. If this information isn't 
enough, then hopefully someone else more knowledgeable can chime in.

- Jonathna M Davis