On 04/10/2013 04:15 AM, Alice Wonder wrote:
> Hello list,
> This is neither LFS nor BLFS so I think this list is best?
Well, BLFS-Support is still the correct list for support questions
whether the package in question is a part of the BLFS book or not. I'm
not sure if this qualifies though...guess it is as good as anyplace, but
you'll get more eyes on blfs-support.
>
> Built a LFS 7.3 system and first thing I did was build the necessary
> dependencies (according to BLFS instructions for them) to build the RPM
> Package Manager.
>
> What I would like to do, and I'll need to do it before I start
> bootstrapping the system in RPM, is delete the /lib64 and /usr/lib64
> symlinks and create directories in their place so that 64 bit shared
> libraries can go into them.
>
> This will likely break building at least temporarily.
>
You are better off not messing with the build host at all. Build all of
your packages first, install (using the build host) all of the packages
onto the target partition, then boot into it and continue.
> Plan to fix building is to initially create symlinks for the libraries
> in {,usr}/lib pointing to {,usr}/lib64 and a symlink in /usr/lib for
> pkgconfig pointing to ../lib64/pkgconfig
Don't do that, it will break multilib should you ever need it.
>
> eventually as I rebuild everything in RPM the pkg-config files should
> correctly point to 64-bit specific library paths and the pkgconfig
> symlink and the library symlinks can be deleted.
>
> libtool .la files - I'll back them up somewhere but I really would like
> to get rid of them, Fedora world got rid of them long time ago, they
> cause problems (as does rpath)
>
> other than pkg-config files, is there anything else anyone can think of
> that might end up biting me?
>
Use --libdir and friends in every invocation of configure, regardless of
whether it is actually needed or not. :-) Look at existing SRPMS.
> I have no intent of trying to go multilib but if there ever is a need I
> would like it to be as painless as possible and 64-bit specific
> libraries and data files (kernel modules excepted) in 64-bit specific
> directory makes sense because it is already being done that way on other
> multilib RPM based systems.
This is really still up in the air...the FHS standard says it is the
correct way. ABI obviously requires this layout for pre-built binaries,
but Debian is already using multiarch in production, and previously used
/lib and /lib32 in their multilib systems (arguably the correct way to
do things). Red Hat has a multiarch ISO available, but not production
yet (if ever? I haven't kept up lately). I haven't seen anything more
than rumblings about SUSE...I think mostly just people confusing the
terms multilib and multiarch. Look up the Debian multiarch proposal for
more info. This is the direction I really hope to see things go in the
future (so that the ridiculous /lib vs. /lib<qual> debate doesn't come
up again in another <10 years).
HTH
--DJ
--
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
