Your scheme works, though I had to add the switch:
--no-warn-search-mismatch
to the linker command.
Jonathan M Davis wrote:
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
