Imagemagick detects features at runtime by the presence of installed libtool archives (.la) files, which are not installed by default with slibtool.... To fix this media-gfx/imagemagick must be built with 'rclibtool' or 'rdclibtool' (Debug version). Reproducible: Always
Its a lot easier to read in the bug list the other way...
(In reply to orbea from comment #1) > Its a lot easier to read in the bug list the other way... The bugs depend on this, though. It's not the other way around. You need to fix IM, not fix lots of other packages. Otherwise it looks like *other people* need to work on their individual apckages.
*** Bug 914060 has been marked as a duplicate of this bug. ***
*** Bug 913679 has been marked as a duplicate of this bug. ***
*** Bug 913924 has been marked as a duplicate of this bug. ***
*** Bug 913695 has been marked as a duplicate of this bug. ***
*** Bug 913865 has been marked as a duplicate of this bug. ***
*** Bug 914150 has been marked as a duplicate of this bug. ***
*** Bug 922599 has been marked as a duplicate of this bug. ***
There is an upstream pull request that might fix this for us some day, https://github.com/ImageMagick/ImageMagick/pull/6940 but in the meantime, this is a quiet breakage that is affecting the tinderbox, so I think we should try to fix it. The first thing I tried was to patch the Makefile to install the *.la files manually. This actually isn't too hard: you can cat >> the new target in src_install, and the build system provides the install locations $CODER_PATH and $FILTER_PATH for you. Pros: short. Cons: intrusive and ugly. My second attempt was to hack the slibtool implementation. There are several slibtool symlinks that do slightly different things: https://wiki.gentoo.org/wiki/Slibtool So the "problem" in this case is that users have to pick one, and the one they're going to pick (rlibtool) isn't going to do what imagemagick needs it to do. There really aren't that many cases to consider, though. So while it's a bit longer, and it sucks to put slibtool implementation details inside of an imagemagick ebuild (it doesn't suck enough for me to want to write a new eclass), I think this solution ends up being simpler and less intrusive. Here's a new function to call in e.g. src_prepare. im-fix-slibtool() { # Most variants of slibtool do not install .la files, but # imagemagick uses them for its coders and filters (bug 926418). On # Gentoo, users typically set LIBTOOL (to the desired variant), # MAKEFLAGS (to LIBTOOL=...), and MAKE (to "make LIBTOOL=...") to # ensure that their preferred variant is used. This function tries # to convert LIBTOOL, if it is set, to a variant that will install # the .la files. # # Ref: https://wiki.gentoo.org/wiki/Slibtool # local _changed=0 case "${LIBTOOL}" in slibtool*) LIBTOOL=rclibtool _changed=1 ;; rlibtool) LIBTOOL=rclibtool _changed=1 ;; rdlibtool|dlibtool*) LIBTOOL=rdclibtool _changed=1 ;; esac # Don't try to parse MAKE(FLAGS). Instead, override any existing # LIBTOOL= assignments with our own. if [[ $_changed -eq 1 ]]; then einfo "Overriding LIBTOOL to install *.la files (bug 926418)" export LIBTOOL export MAKEFLAGS+=" LIBTOOL=${LIBTOOL}" export MAKE+=" LIBTOOL=${LIBTOOL}" fi } CC: sam for graphicsmagick which I assume has the same problem
I'd much prefer that we direct people to use an slibtool 'binary' that does the right thing and doesn't break legitimate, even if unusual, use of .la files. See 58128e2701881192e5d551d6b1d27bac3f6cde58 for toolchain.eclass. What's the real benefit of people using the versions which break stuff? It doesn't help the other Gentoo users who use GNU libtool (for packages where.la is unnecessary and we should delete it).
(In reply to Sam James from comment #11) > I'd much prefer that we direct people to use an slibtool 'binary' that does > the right thing and doesn't break legitimate, even if unusual, use of .la > files. > > See 58128e2701881192e5d551d6b1d27bac3f6cde58 for toolchain.eclass. > > What's the real benefit of people using the versions which break stuff? It > doesn't help the other Gentoo users who use GNU libtool (for packages > where.la is unnecessary and we should delete it). I would be fine with that as well. rlibtool is just one of the symlinks that will do the wrong thing, though, so we should catch the others and make appropriate suggestions, e.g. case "${LIBTOOL}" in slibtool*) die "use rclibtool instead" ;; rlibtool) die "use rclibtool instead" ;; rdlibtool|dlibtool*) die "use rdclibtool instead" ;; esac And then, the main thing I guess would be to update the wiki page to suggest rclibtool instead of rlibtool by default. Otherwise it could get pretty annoying to have a bunch of ebuilds that die and tell you to edit your make.conf.
(In reply to Michael Orlitzky from comment #12) > And then, the main thing I guess would be to update the wiki page to suggest > rclibtool instead of rlibtool by default. Otherwise it could get pretty > annoying to have a bunch of ebuilds that die and tell you to edit your > make.conf. I tried that at https://wiki.gentoo.org/index.php?title=Slibtool&diff=1315196&oldid=1283926 It was reverted and edit-warred and reverted again with https://wiki.gentoo.org/index.php?title=Slibtool&diff=1315652&oldid=1315507 After some discussion on IRC with midipix it appears that midipix does NOT after all insist that nobody should use rclibtool, but in fact seems to be entirely fine with distros establishing their own policy however they like. So maybe we should in fact restore my original edit. I had rationalized my original edit with the logic that it is an ebuild bug to be missing the "find ${ED} -name '*.la' -delete", since ebuilds must support people who use the default GNU Libtool which does install those files; thus, there is no downside to globally using (recommending in the wiki) rclibtool, safe in the knowledge that "whether or not to skip installing those files" is a decision encoded outside of slibtool, and rather encoded in the ebuild.
FWIW this will be fixed when this Slibtool issue is addressed. https://dev.midipix.org/cross/slibtool/issue/74
Also I strongly suggest against using rclibtool everywhere, its not needed in most places and these issues can be fixed in better ways. However in the wiki discussion none of the points were addressed and it was forced in the toolchain eclass instead without discussion. For gcc I wonder if autoreconf would fix it, but it would need the toolchain devs to help with that.
Using slibtool/rlibtool has helped find & fix a large number of upstream bugs, so I understand the reluctance to switch it to the compatibility wrapper. But in these three cases (IM, GM, and GCC) there is no bug. They are using libltdl in the way it's meant to be used, to abstract away the platform-dependent bits of dlopen. The list of slibtool blockers (bug 765709) is now pretty small, so we are approaching a situation where a considerable portion of the blockers are things that aren't bugs and will probably never be "fixed." At some point I think we would like users to actually be able to use slibtool, though, right? I think that leaves us only a few options: Option A: Use die statements to suggest rclibtool for packages that need it A1: Leave "rlibtool" as the suggestion, and mention rclibtool more prominently. This has the downside that users will hit the "die," but if we send them to the wiki it will probably be a one-time thing. Of course the end result is that they'll wind up using rclibtool and not rlibtool, despite the default suggestion. A2: Change the default suggestion to "rclibtool", and mention that rlibtool will skip the .la files and is better for testing and bug reporting, but probably only for developers. Option B: Do something like comment 10 instead of die(), and leave "rlibtool" as the suggestion. Both A & B are creating redundant (with find -name *.la -delete) whitelists of packages that need their .la files. B is more heavy-handed but would let us keep rlibtool as the suggestion. On the other hand, as I mentioned, the list of actual bugs is getting pretty short, and the list of exceptions is of length >= 3. I think (A2) is pretty reasonable. If we want to do a tinderbox run with LIBTOOL=rlibtool again, package.env can be used to bypass the packages that die().
(In reply to orbea from comment #15) > Also I strongly suggest against using rclibtool everywhere, its not needed > in most places and these issues can be fixed in better ways. (I was typing my last comment while you sent this) I get this, but realistically, is anyone going to fix these important packages while we wait? They're not technically broken, so it's pretty hard to pitch it upstream as some kind of emergency when the problem is a few bytes' worth of .la files and it only affects a libtool implementation they've never heard of.
> I get this, but realistically, is anyone going to fix these important packages while we wait? I have been and am still willing to work on these with the caveat that most PRs I make are ignored for extended periods of time which entirely saps my energy to work on anything I do not personally maintain or use. (Since by time someone gets to these PRs they are often outdated and I have forgotten the pertinent details) For the case of imagemagick this is already solved if sltdl + slibtoolize are used, but the linked slibtool issue is required to easily use sltdl without hacking imagemagick. I messaged midipix about this again, but he has been very busy with unrelated concerns lately. For gcc I suspect autoreconf will solve this, but it needs someone that knows how to autoreconf gcc to solve this. For gdb autoreconf will certainly solve this, but again the same problem. I am not sure of any other cases?
(In reply to Michael Orlitzky from comment #16) > Using slibtool/rlibtool has helped find & fix a large number of upstream > bugs, so I understand the reluctance to switch it to the compatibility > wrapper. But in these three cases (IM, GM, and GCC) there is no bug. They > are using libltdl in the way it's meant to be used, to abstract away the > platform-dependent bits of dlopen. There are roughly two types of bugs commonly encountered with slibtool, I think: - packages which are not -Wl,--no-undefined clean, which is in general a horrible code smell (meson and slibtool do this by default, GNU libtool does not) - packages which obscurely need .la files, either at build time or runtime Gentoo removing .la files predates the effort to use slibtool in Gentoo. It's not obvious to me that slibtool moved the needle here. Gentoo is also hardly the only distro to do this. (In reply to Michael Orlitzky from comment #17) > I get this, but realistically, is anyone going to fix these important > packages while we wait? They're not technically broken, so it's pretty hard > to pitch it upstream as some kind of emergency when the problem is a few > bytes' worth of .la files and it only affects a libtool implementation > they've never heard of. In the toolchain case specifically, the toolchain developers who are gentoo developers with commit bits upstream have stated that the upstream stance is that not only are they not technically broken, but that they use a forked GNU libtool with customizations that are incompatible with GNU libtool and they are skeptical that slibtool can work anyway. Also, they are using .la files generated inside the compilation worktree as load-bearing parts of their build logic. They don't care if they are installed AFAIK but their Makefile rules utilize them to make cross-subdir decisions. There is some context in bug 932245 including the ::gentoo commit to toolchain.eclass (but the GCC devs discussion happened on IRC) Their interest in "fixing these important packages" reaches astronomically negative levels, which is why... (In reply to orbea from comment #15) > However in the wiki discussion none of the points were addressed and it was > forced in the toolchain eclass instead without discussion. For gcc I wonder > if autoreconf would fix it, but it would need the toolchain devs to help > with that. ... there is nothing to discuss on the wiki, autoreconf will not help, it was in fact discussed with the relevant parties and those relevant parties simply didn't happen to be slibtool. There is no point talking about how "libtool behavior is gross and I don't like it and people should simply stop depending on that" when the fact of the matter is: - GCC is broken today if you use rlibtool without "c" - GCC does not intend to change - Gentoo's toolchain team wishes to not have to deal with bug reports from people who emerged sys-devel/gcc and broke their system That third point is critical. As far as I'm concerned you're more than welcome to discuss changing GCC with the GCC upstream developers. But when Gentoo *knows* that a package currently packaged today is broken (that is, emerge succeeds at installing the package, but the resulting installed software is buggy) when emerged with rlibtool, Gentoo is going to ***fix that package*** by preventing it from being broken, as a damage control mechanism. Nobody has a right to discussion being a blocker for blocking the Gentoo toolchain team from fixing user systems ASAP. Discussion is for after. It does you no credit at all to keep complaining that toolchain.eclass was "forced without discussion". I respect your right to believe that my wiki interactions about non-toolchain packages did me no credit either. But you need to leave the toolchain out of this discussion. Thanks.
ETOOMUCHTEXT I don't see slibtool support as really critical, so please ping me with a tl;dr once you've figured out a solution.
That is more or less the answer I expected for GCC, and is the reality we have to work within. If the toolchain eclass is going to die and tell people to use rclibtool, image/graphicsmagick might as well die and tell people to use rclibtool, too. Even if slibtoolize is changed to use sltdl (there is no guarantee of this), that will only help so long as the affected packages need to call eautoreconf. And I suspect that maintainers of other packages may be of a similar disposition as the GCC maintainers if asked to keep an eautoreconf around just for the sake of the 'c' in rlibtool. So my suggestion is something like the following in pkg_setup: case "${LIBTOOL}" in slibtool*) die ".la files are important for this package, please use rclibtool instead" ;; rlibtool) die ".la files are important for this package, please use rclibtool instead" ;; rdlibtool|dlibtool*) die ".la files are important for this package, please use rdclibtool instead" ;; esac At that point I think it makes sense to update the wiki, because people are going to change LIBTOOL to rclibtool anyway (everyone uses toolchain.eclass), but I don't want to fight over it. We can leave it alone if there's still a debate.
Sorry for slow replies, I have been under the weather the last week and am still trying to catch up. > There are roughly two types of bugs commonly encountered with slibtool FWIW there are a lot more issues than that, the Gentoo slibtool wiki page documents a lot of them. > In the toolchain case specifically, the toolchain developers who are gentoo > developers with commit bits upstream have stated that the upstream stance is > that not only are they not technically broken, but that they use a forked GNU > libtool with customizations that are incompatible with GNU libtool and they > are skeptical that slibtool can work anyway. Upstream GCC devs have explicitly fixed issues revealed by slibtool before. https://bugs.gentoo.org/767706 > ... there is nothing to discuss on the wiki, autoreconf will not help, How do you know? Has it been tried? Regardless this is about imagemagick and I think this will be resolved as soon as midipix has time.
@Michael Orlitzky I made a PR to resolve issues like this, but since then I fixed most of the relevant issues in better ways so I closed it. Perhaps something like this could be finished instead? Probably would still help dialog at least. https://github.com/gentoo/gentoo/pull/25411
The .la thing is different because it's a choice being made to be different and it's hard to even make the argument people should support that. I think it's reasonable for us to say we're not bothered about that case in Gentoo, at least right now.
(In reply to Michael Orlitzky from comment #21) > At that point I think it makes sense to update the wiki, because people are > going to change LIBTOOL to rclibtool anyway (everyone uses > toolchain.eclass), but I don't want to fight over it. We can leave it alone > if there's still a debate. Yes, I'd like us to do that.
(In reply to Sam James from comment #24) > The .la thing is different because it's a choice being made to be different > and it's hard to even make the argument people should support that. I think > it's reasonable for us to say we're not bothered about that case in Gentoo, > at least right now. +1 I would expect GCC upstream to be amenable to arguments that what they are doing is "wrong" according to libtool even if it silently works, and choosing to fix the "officially wrong" behavior for the sake of alternative implementations. The .la thing is, however, using libtool in the documented manner by which libtool is *supposed* to behave, so I don't expect any interest in "fixing that which is not broken" (and that's the reaction I received: that essentially "it isn't broken so I am casting a vote against changing anything").
(In reply to orbea from comment #23) > @Michael Orlitzky > > I made a PR to resolve issues like this, but since then I fixed most of the > relevant issues in better ways so I closed it. Perhaps something like this > could be finished instead? Probably would still help dialog at least. > > https://github.com/gentoo/gentoo/pull/25411 I found an easy workaround for dev-util/dialog: https://bugs.gentoo.org/778047#c11 We may still ultimately need something like your elibtool function, but I guess it depends on how many of the remaining bugs cannot be fixed in a better way.
