Armin K. wrote: > No matter what you say, if a package A installs a file X.Y that requires > file Z.Y and package A doesn't either: > > a) pull automatically the package (depend on) that contains file Z.Y > b)ships that file itself > > the packaging is broken.
Then BLFS's and LFS's "packaging" are broken, because neither of them does dependencies. (And nothing pulls them automatically.) In LFS there's an order of installation that hopefully covers everything, and we try to either fix up builds (via configure flags or whatever) or provide new deps as they're discovered, but that's not always perfect. In BLFS there's the list of dependent packages (and it even does optional / required, which is great!), but it doesn't do anything automatic. My understanding of Slackware (which is rather limited) is that its packaging has no automatic dependencies either. Yes, this makes it possible to have a system that doesn't work right. But no, I don't think that's an excuse to say that it's "broken". An individual system, maybe, but not "the packaging". > Again, it's irrelevant if mpfr uses host mpfr or not since the target > library is static library and it won't pull host dependencies at all. Um, no, actually. These are .la files, not .a files. There are no static libs in sight. > You couldn't install a package that contains libmpfr.so and libmpfr.la (the > -dev package) on Debian without it pulling package that contains libgmp.so > and libgmp.la. And in Slackware, there is no such thing as a "pulling" of other packages; just like in BLFS. In this particular case, if I understand everything I've read correctly, I think that either (a) a warning but not an error if any of the three libtool files are present, or (b) a fix to the gcc build or build system to not use them from the host at all, would be right. But (b) is rather harder, and not likely to happen during an -rc anyway. I wonder if we can make libtool work right. Looking at gcc's ltmain.sh, line 5309 is where the host paths are getting in there for libtool --mode=link -o foo.la, and line 5311 is where the host paths are getting in there for libtool --mode=link -o foo (i.e. a program). But it's not entirely clear where all the directory searches are coming from... Maybe adding a --debug to the libtool invocation that fails would help figure out why it's pulling .la files from the host, as opposed to from the build tree where they're supposed to be pulled from? If anyone has a system that's in this unbuildable state, that --debug info might help. I'd recommend running the make that fails, then taking just the last command and adding --debug to it, and saving the output somewhere (it turns on "set -x", so there will be a ton of it).
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
