Re: Friday lsbsi status

On Fri, 2004-02-20 at 16:27, Wichmann, Mats D wrote:
> I'll update this into the report that will
> be found at http://www.linuxbase.org/impl/records.html,
> but in the meantime here's a short summary
> purely for the lsbsi:
> 
> 
> Package uplifiting (match current upstream
> versions were possible):
> 
> Mostly done.  Remaining: 
> - shadow 4.0.4.1 is available, try this to see 
> if it fixes the one newgrp failure that was
> present in 4.0.3
> - bison 1.875
> - X11: currently on 4.2, 4.3 appears to require
> a more complicated build so this was put off.
> /May/ be needed for newer platforms (amd64,
> ppc64, etc.).  There's also an alternate source
> for xlibs, now released by freedesktop.org,
> state unknown.
> 
> Notable: rpm was uplifted to 4.1.  There seems
> no reason to stay with 3.0.6, and 4.x is 
> needed for support of x86_64.  We were able
> to drop the build of db3 as it is now built
> locally to rpm.
> 
> =====================================
> 
> Known problems:
> - on x86, builds all the way to completion,
> but in the final steps, when rpm is run to
> initialize an empty database, it fails because
> it uses a library (libbz2) which is not
> installed. libbz2 was installed in phase2,
> so it's picked up by the build there.  
> 
> - ppc built correctly before the last round
> of changes. At the least it now has the same
> problem as x86 above. There was a report of
> poor test results; it's not verified whether
> this was a setup problem.
> 
> - on s390/s390x, there seems to be a toolchain
> mismatch, some header file problems appear
> building glibc at the start of phase2. This
> probably means something incorrect was
> installed during the bootstrap, a likely guess
> is it's the kernel-headers package.
> 
> - on ia64, dies with a strange toolchain problem:
>   malloc: jobs.c:725: assertion botched
>   free: called with already freed block argument
> Is  this familiar to anyone?
> 
> - on ppc64, there are questions whether the
> toolchain will build 64-bit native all the
> way through.  That's the current design of
> the lsbsi build; ppc64, on the other hand,
> normally ships as a 32-bit environment with
> 64-bit libraries.
> 
> - on amd64, the build goes through to the end
> of phase2, where it fails on xfree86. See
> note above.
> 
> - generic /lib64:  a number of packages
> are still putting libraries in /lib
> or /usr/lib instead of /lib64 or /usr/lib64.
> This will need a cleanup pass.  Sometimes
> this is package configuration; sometimes
> this is the install-phase "manual"
> fiddling that is done in our xml files.
> 
> - generic bi-arch:  current glibc/gcc/binutils
> have biarch capability. We are not enabling
> (and sometmes explicitly disabling) this.
> Should we turn this on eventually?

Difficult issue. Biarch is an important feature of some architectures.
It is also a pain to maintain it. Enabling biarch would also mean that
we'd have so provide 32bit versions of all the libs. I don't know if
(and kinda doubt that) the current build/bootstrap scheme will be able
to provide those without major hacks. As time is short as it is, I
propose to leave it out for now but to keep it in mind. Maybe LSB 2.1
could address the issue.

BB

 
> 
> _______________________________________________
> lsb-impl mailing list
> [email protected]
> http://freestandards.org/mailman/listinfo/lsb-impl
>

_______________________________________________
lsb-impl mailing list
[email protected]
http://freestandards.org/mailman/listinfo/lsb-impl

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBANi8pF4rfSDwQ+joRAvtyAKCRHmKKKI0F/3+6JHffC40NrYddwgCeJDD2
8IvYAWnbKHUZ6H3wOwMlMYI=
=U+24
-----END PGP SIGNATURE-----