Thanks, I think I'll give this schema a try and see how it works. -Walter
Jonathan M Davis wrote:
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...@p%/../lib from the current dmd.conf and add -l...@p%/../lib32
and -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
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
