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
