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

This is strange. The following works for me.
hello.d:
import std.stdio;
void main() {
    writeln("Hello World");
}

$ dmd -c hello.d
$ gcc -m32 hello.o -o hello -L/home/jkm/local/x86_64-linux-gnu/lib -lphobos2 -lpthread
$ ./hello
Hello World

I using phobos2 here. I suppose there is something wrong with your libphobos.a because it gets ignored.

Jens

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-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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
> 

On Friday 07 January 2011 19:25:17 Walter Bright wrote:
> Your scheme works, though I had to add the switch:
> 
>    --no-warn-search-mismatch
> 
> to the linker command.

Well, that's good to hear, though I find it interesting that you had to add that flag. By all evidence, I would have thought that gcc did that already. Hopefully, you still get a sensible enough error when you don't have the correct library version but you do have the library - though my guess would be that it would simply tell you that it couldn't find it rather than telling you that it found a mismatch if it doesn't find the correct one, which would be less useful than telling you that the one that it found was the wrong one, but it wouldn't usually be an issue, and if you had libphobos.a on the path, and it didn't work, then the most obvious question would be whether it was for the right architecture, which is easy enough to figure out. So, I wouldn't expect it to be much of a problem, even if it wouldn't be ideal. Regardless, at least you were able to finally get something working.

- Jonathan M Davis