Request for filesystem layout change in next amd64 suse.
Hi there, I've been using the amd64 suse destro's since 9, and I have in that time come across a number of issues with default configure/build scripts not picking up the 64 suffix of various libraries scattered across the system. If all configure/build scripts contained the enable libsuffix option this wouldn't be a problem, but not all of them do... One of the ugly hacks I use to get around this is to mv the lib dir of whatever library is not being picked up to lib32 and then symlink lib to lib64 for the duration of the build... this is ugly but the only way to get around this issue. My request is that libraries be layed out so that all 32bit libs contain the suffix 32 so for instance qt3 resides in /usr/lib64/qt3/ (actually it's a symlink but it doesn't matter) and contains a lib and a lib64 dir within that directory (this is the same for a number of libraries), if you are trying to compile an app which doesn't pick up the llib64 dir as the correct one it will fail... In this case what would happen is that /usr/lib64/qt3/lib would become /usr/lib64/qt3/lib32 and a symlink to lib would exist to the correct library set for the parent /usr/lib64 (i.e lib would point to lib64 in this case).... This would resolve alot of issues... It's not a trivial thing... but I think would greatly improve the usability of suse as a build environment. Implementation wise i'm open to suggestions.. but consider this a formal request out of hours of fiddling with library parths to get joe random thing to compile... Kind regards Joel W
Slashdot score: (5, Very funny) [sorry, I couldn't resist :D ] Take it from the other side - SUSE *is* able to build the whole distribution whith this filesystem layout. So does RedHat, Mandrake and others. Why not Joe Random? Shouldn't he fix his package instead? Michal Ludvig Joel Wiramu Pauling wrote:
Hi there,
I've been using the amd64 suse destro's since 9, and I have in that time come across a number of issues with default configure/build scripts not picking up the 64 suffix of various libraries scattered across the system. If all configure/build scripts contained the enable libsuffix option this wouldn't be a problem, but not all of them do...
One of the ugly hacks I use to get around this is to mv the lib dir of whatever library is not being picked up to lib32 and then symlink lib to lib64 for the duration of the build... this is ugly but the only way to get around this issue.
My request is that libraries be layed out so that all 32bit libs contain the suffix 32 so for instance qt3 resides in /usr/lib64/qt3/ (actually it's a symlink but it doesn't matter) and contains a lib and a lib64 dir within that directory (this is the same for a number of libraries), if you are trying to compile an app which doesn't pick up the llib64 dir as the correct one it will fail...
In this case what would happen is that /usr/lib64/qt3/lib would become /usr/lib64/qt3/lib32 and a symlink to lib would exist to the correct library set for the parent /usr/lib64 (i.e lib would point to lib64 in this case).... This would resolve alot of issues...
It's not a trivial thing... but I think would greatly improve the usability of suse as a build environment.
Implementation wise i'm open to suggestions.. but consider this a formal request out of hours of fiddling with library parths to get joe random thing to compile...
Yup I agree, but at the same time, why on a native 64bit platform are the lib directory's actually the 32bit libraries and not the 'expected' standard native platform librarys??? Because suse ( I can't comment on redhat) have violated the standard... thus changing the situation more in an already broken system.. to try and bring it back to somthing approaching sanity, is a better option than expecting everyone to add fixes to there build systems for 'broken' distro's like suse. Debian takes this stance, as does gentoo on the location of native system libraries (i.e don't mix them at all) So slashdot.. funy mod +5 maybe... But probably more a +5 controversial if one exists... Most post is there to stir debate, and hopefully my argue does make sense.
On 2005-03-01 23:21:57 +1300, Joel Wiramu Pauling wrote:
Yup I agree, but at the same time, why on a native 64bit platform are the lib directory's actually the 32bit libraries and not the 'expected' standard native platform librarys??? Because suse ( I can't comment on
Because the system is biarch. Your discussion is better suited for the FHS group (http://www.pathname.com/fhs/); please take it there. Best regards Martin PS: Please learn to quote. -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On Tuesday 01 March 2005 11:27, Martin Schröder wrote:
Because the system is biarch.
The native and 32bit system are not completely separated in SuSE. Yast can remove the majority of *-32bit-* packages, but if you will try to remove glibc-32bit* (with yast) bad things happen. Oleg.
Martin Schröder
On 2005-03-01 23:21:57 +1300, Joel Wiramu Pauling wrote:
Yup I agree, but at the same time, why on a native 64bit platform are the lib directory's actually the 32bit libraries and not the 'expected' standard native platform librarys??? Because suse ( I can't comment on
Because the system is biarch.
Your discussion is better suited for the FHS group (http://www.pathname.com/fhs/); please take it there.
The FHS specificies lib64 for x86-64 systems already for some time, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 2005-03-01 17:27:01 +0100, Andreas Jaeger wrote:
The FHS specificies lib64 for x86-64 systems already for some time,
----------- This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them. ----------- So when will /lib be a symlink to /lib64? Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
Martin Schröder
On 2005-03-01 17:27:01 +0100, Andreas Jaeger wrote:
The FHS specificies lib64 for x86-64 systems already for some time,
----------- This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them. -----------
So when will /lib be a symlink to /lib64?
Did you read it completly? The relevant section is the following: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
participants (5)
-
Andreas Jaeger -
Joel Wiramu Pauling -
Martin Schröder -
Michal Ludvig -
Oleg Gusev