January 03, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips |
Jesse Phillips wrote:
>
> I think the linker already ignores libraries of the wrong architecture.
>
>
No, it barfs on it.
|
January 03, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Or even better, just go with: libphobos.a 32 bit library libphobos-64.a 64 bit library and: libphobos2.a 32 bit library libphobos2-64.a 64 bit library simple, easy, doesn't break anything. |
January 04, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter, DMD 1 looks for libphobos.a whilst DMD 2 looks for libphobos2.a This has turned out to be a minor irritant for SCons. Currently DMD 1 and DMD 2 both have dmd, rdmd, etc. so the command names are all the same yet the library name is different. DMD 1 and DMD 2 could coexist -- which they cannot do currently -- if DMD 2 had dmd2, rdmd2, etc. with libphobos2.a to match. On Mon, 2011-01-03 at 14:48 -0800, Walter Bright wrote: > Currently, dmd simply looks for libphobos.a > > I suggest changing it to: > > lib32/libphobos.a for -m32 > lib64/libphobos.a for -m64 > _______________________________________________ > phobos mailing list > phobos at puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110104/d36d5844/attachment.pgp> |
January 04, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter, I think your naming proposal here will lead to serious problems. Speaking from a very Linux, indeed Debian and Ubuntu, centred perspective, my machines have a natural bit width and so /usr/lib relates to the natural bit width. 64-bit in may case. There is also /usr/lib32 and /usr/lib64. In my case /usr/lib64 is a symbolic link to /usr/lib. /usr/lib32 cotnains all the 32-bit libraries etc. In all cases the name of a library is always the same, e.g. libphobos2.a no matter what the bit width. Obviously the DMD distribution can do what it likes as it doesn't actually interact with /usr since it is not coming in via a package (as 32-bit packages should not be installed on a 64-bit platform -- see above). The problem is though that the DMD distribution should not do anything that makes it hard for Debian, Ubuntu, Fedora, RHEL, etc. packagers to work within the rules of their distribution. On Mon, 2011-01-03 at 22:37 -0800, Walter Bright wrote: > Or even better, just go with: > > libphobos.a 32 bit library > libphobos-64.a 64 bit library > > and: > > libphobos2.a 32 bit library > libphobos2-64.a 64 bit library > > simple, easy, doesn't break anything. > _______________________________________________ > phobos mailing list > phobos at puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110104/e4e9e36d/attachment-0001.pgp> |
January 04, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Yes, I prefer this.
-Steve
----- Original Message ----
> From: Walter Bright <walter at digitalmars.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Tue, January 4, 2011 1:37:45 AM
> Subject: Re: [phobos] 32 and 64 bit libraries on Linux
>
>
> Or even better, just go with:
>
> libphobos.a 32 bit library
> libphobos-64.a 64 bit library
>
> and:
>
> libphobos2.a 32 bit library
> libphobos2-64.a 64 bit library
>
> simple, easy, doesn't break anything.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
|
January 04, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | So, is this what happens:
gcc => looks in /usr/lib
gcc -m32 => looks in /usr/lib32
gcc -m64 => looks in /usr/lib64
?
Russel Winder wrote:
> Walter,
>
> I think your naming proposal here will lead to serious problems.
> Speaking from a very Linux, indeed Debian and Ubuntu, centred
> perspective, my machines have a natural bit width and so /usr/lib
> relates to the natural bit width. 64-bit in may case. There is
> also /usr/lib32 and /usr/lib64. In my case /usr/lib64 is a symbolic
> link to /usr/lib. /usr/lib32 cotnains all the 32-bit libraries etc. In
> all cases the name of a library is always the same, e.g. libphobos2.a no
> matter what the bit width.
>
> Obviously the DMD distribution can do what it likes as it doesn't actually interact with /usr since it is not coming in via a package (as 32-bit packages should not be installed on a 64-bit platform -- see above). The problem is though that the DMD distribution should not do anything that makes it hard for Debian, Ubuntu, Fedora, RHEL, etc. packagers to work within the rules of their distribution.
>
> On Mon, 2011-01-03 at 22:37 -0800, Walter Bright wrote:
>
>> Or even better, just go with:
>>
>> libphobos.a 32 bit library
>> libphobos-64.a 64 bit library
>>
>> and:
>>
>> libphobos2.a 32 bit library
>> libphobos2-64.a 64 bit library
>>
>> simple, easy, doesn't break anything.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
|
January 04, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, January 04, 2011 11:59:46 Walter Bright wrote:
> So, is this what happens:
>
> gcc => looks in /usr/lib
> gcc -m32 => looks in /usr/lib32
> gcc -m64 => looks in /usr/lib64
>
> ?
No. It's definitely smart enough to figure out whether libraries are 64 bit or not and deal with it. I believe that it looks in /lib, /usr/lib, and /usr/local/lib by default, but it also looks in the directories listed in /etc/ld.so.conf. On my 64-bit SuSE box, ld.so.conf contains:
/usr/X11R6/lib64/Xaw3d
/usr/X11R6/lib64
/usr/lib64/Xaw3d
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib
/usr/lib/Xaw3d
/usr/x86_64-suse-linux/lib
/usr/local/lib
/opt/kde3/lib
/lib64
/lib
/usr/lib64
/usr/lib
/usr/local/lib64
/opt/kde3/lib64
include /etc/ld.so.conf.d/*.conf
Notice that the 64-bit and 32-bit library directories are completely mixed. ld is somehow able to determine whether a library is 32-bit or 64-bit and use the correct one. And while it does list /lib, /usr/lib, and /usr/local/lib in that ld.so.conf, the one of my 32-bit Arch box doesn't have any, so it's obviously able to find at least /lib and /usr/lib without an ld.so.conf.
So, why you were finding that gcc was barfing on the wrong library type, I don't know. Maybe you gave it to it directly or something, rather then letting it find it. But gcc can definitely find the correct library without understanding which directories hold which types of libraries.
- Jonathan M Davis
|
January 04, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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? Jonathan M Davis wrote: > On Tuesday, January 04, 2011 11:59:46 Walter Bright wrote: > >> So, is this what happens: >> >> gcc => looks in /usr/lib >> gcc -m32 => looks in /usr/lib32 >> gcc -m64 => looks in /usr/lib64 >> >> ? >> > > No. It's definitely smart enough to figure out whether libraries are 64 bit or not and deal with it. I believe that it looks in /lib, /usr/lib, and /usr/local/lib by default, but it also looks in the directories listed in /etc/ld.so.conf. On my 64-bit SuSE box, ld.so.conf contains: > > /usr/X11R6/lib64/Xaw3d > /usr/X11R6/lib64 > /usr/lib64/Xaw3d > /usr/X11R6/lib/Xaw3d > /usr/X11R6/lib > /usr/lib/Xaw3d > /usr/x86_64-suse-linux/lib > /usr/local/lib > /opt/kde3/lib > /lib64 > /lib > /usr/lib64 > /usr/lib > /usr/local/lib64 > /opt/kde3/lib64 > include /etc/ld.so.conf.d/*.conf > > Notice that the 64-bit and 32-bit library directories are completely mixed. ld is somehow able to determine whether a library is 32-bit or 64-bit and use the correct one. And while it does list /lib, /usr/lib, and /usr/local/lib in that ld.so.conf, the one of my 32-bit Arch box doesn't have any, so it's obviously able to find at least /lib and /usr/lib without an ld.so.conf. > > So, why you were finding that gcc was barfing on the wrong library type, I don't know. Maybe you gave it to it directly or something, rather then letting it find it. But gcc can definitely find the correct library without understanding which directories hold which types of libraries. > > - Jonathan M Davis > _______________________________________________ > phobos mailing list > phobos at puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos > > > |
January 04, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
January 04, 2011 [phobos] 32 and 64 bit libraries on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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-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
>
>
>
|
Copyright © 1999-2021 by the D Language Foundation