Re: amd64(gcc4): aptitude dumps core
On 05-Jan-13 23:55, Frederik Schueler wrote:
> Hi,
>
> On Thu, Jan 13, 2005 at 09:24:53PM +0100, Andreas Jochens wrote:
> > On the other hand, I know that you disagree with some of my decisions
> > for the gcc-3.4 archive, especially the decision to change the location
> > of the linker to '/lib' instead of '/lib64'. I think that '/lib64' will
> > be abandoned in the long run and therefore I do not like the idea to
> > introduce it in the first place. Call this broken if you like.
>
> This is not broken, this simply violates the LSB[1] and makes the port
> incompatible to other distros.
No, this does not violate the LSB. This is a common misunderstanding.
The LSB defines its own interpreter name as '/lib64/ld-lsb-x86-64.so.2'
(note the '-lsb-' part in the name).
Neither pure64 nor the gcc-3.4 archive use this LSB name. Pure64 uses
'/lib64/ld-linux-x86-64.so.2' and gcc-3.4 uses '/lib/ld-linux-x86-64.so.2'.
The LSB conforming interpreter name is provided by the lsb compatibility
package for both the pure64 and the gcc-3.4 archives. This name is
expected to be used by LSB conforming binaries only - not by the normal
binaries from the distribution. (BTW: I do not know of any LSB
conforming applications, do you?)
> I don't like having /lib64 around neither, and I wish amd64 had the
> linker treated the same as on alpha or ia64, since 32bit stuff will be
> legacy in a medium term and the need for 32bit support will fade in
> time. I fully agree with you in this point. But changing it without
> a consensuns among at least the porters on this mailing list is wrong,
> IMHO.
I made that change and recompiled the complete archive with that change
(i.e. without any 'lib64' directories) mainly because I wanted to prove
that this is possible and does not create problems. I found two or three
packages which explicitly used 'lib64' and FTBFS without it. I filed
bugs for those and these packages have been fixed by now.
> We had this topic several times on irc, and we always agreed to not
> break the LSB but keep waiting for the issue to be solved on a
> large scale, including other distros and to culminate in a change of the
> LSB dropping the lib64 requirement. I bet searching the list will show
> similar discussions here.
It will not be necessary to change the LSB. However, both the pure64
and the gcc-3.4 port violate the FHS by not putting 32 bit libraries in
'/lib'. I think the FHS has to be changed to drop the requirement to
put 32 bit libraries in '/lib'.
> The pure64 and gcc-3.4 branches should not compete, we work towards the
Competetition is not always a bad thing. Sometimes more than one
possible solutions has to tested before a decision to finally use
one of them can be made. But of course, the intention of the gcc-3.4
archive is not to compete with pure64. I see it as a means of finding
errors and problem for amd64 and as an opportunity to make the
Debian archive compatible with gcc-3.4 and gcc-4.0.
> same goal of having amd64 included into debian. We must cooperate
> closely with the maintainers of the packages having trouble working on
> amd64, and all the patches you, and the other porters filed proof we are
> doing so. We should keep on going with this, and do major changes only
> in consensus with all involved developers and porters.
I fully agree with you. I would like to thank you and all the other
amd64 porters for all the work you are constantly doing and all the
countless hours you have spent to make the pure64 port as good as it is
now.
Regards
Andreas Jochens
Reply to: