On 03/02/2014 08:05 PM, Bryan Kadzban wrote: > 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". >
Something is. Two people were able to reproduce it using (almost?) the same setup. I must admit that I have never used slackware nor know how it works, but I still think that whatever installs mpfr *.so and *.la files should make sure the same is installed for gmp, too. In LFS we do that by installing gmp before mpfr, so it isn't (and shouldn't be) broken unless you break it yourself by modifying/removing installed files and what not. >> 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. > Pierre's log shows that link fails at linking mpc (not gcc) static library and libtool is (trying to) using (host's) *.la file to get information on how to link against the static mpfr library but it chokes on finding the gmp file which is listed as a dependency in the mpfr .la file. >> 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). > > > -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
