Talk:Slibtool

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 12:24, 5 November 2024 (UTC)
:: Your reply ~~~~

Using libtool compat mode

Talk status

This discussion is still ongoing as of 2024-10-08.

Per recent modification and revert war following my initial implementation of Special:Diff/1315196, I believe this merits a proper discussion. It was initially rolled back without explanation via "undo" -- the "undo" tool used without explanatory reasoning indicates an edit that an ignorant bystander would still agree is correct, typically spam or an accidentally submitted/broken/half-edited page. This wasn't the case here. Someone else reverted the revert noting that and also noting that he thought the change sounded correct. It has now been reverted again, this time at least with an explanation: "per discussion with upstream this should be reported to gcc". Revert wars are not a good thing!!! We should strive to avoid them and to actually discuss the issues.

Maybe its my ignorance on using a wiki, but I did not seem a clear way to elaborate when using the "undo" tool and as it was clearly an incorrect change I used it anyways. You are welcome to PM me on irc or to have tried discussing this with upstream where this would have been explained more clearly. --Orbea (talk) 14:11, 9 October 2024 (UTC)

I challenge that my initial edit was correct. The slibtool wiki page for Gentoo users currently documents the upstream midipix project's suggestion to use "rlibtool", a mode for slibtool that causes slibtool to behave in ways that midipix believes to be superior to GNU libtool. I don't blame them for thinking their own software is superior! :) Many people have that opinion, it's why they write code in the first place. I recommended to use rclibtool instead, which advice is already in the Troubleshooting section. Rationale: bug #932245.

Note with regard to this bug report that it renders the system toolchain nonfunctional in ways that break *other* packages. It is a significant footgun and as a result, attempting to install GCC with LIBTOOL=rlibtool will scold you that rlibtool shouldn't be used at all.

FYI: the bug was open for months blocking the slibtool tracker and the dev-build/slibtool package maintainer has not submitted a GCC bug report as midipix recommends. This is (for obvious reasons) the responsibility of the people who care about slibtool to convince upstreams such as GCC to make changes.

The individual who was involved in reviewing PRs to fix slibtool issues stopped being receptive towards that and I have stopped trying to fix them until that issue is resolved. I have a hard enough time getting PRs for programs I maintain reviewed. --Orbea (talk) 13:58, 9 October 2024 (UTC)

My assertion is that this wiki page isn't the midipix advocacy page for slibtool -- we do not care what midipix believes is great and cool, we care about Gentoo users having systems that are not broken. And I do not understand the midipix rationale to begin with. The point of slibtool as used in Gentoo is to be a drop-in replacement for GNU libtool, which it is not accomplishing unless it implements the features of libtool as expected by software using libtool.

I explained in the main page edit that the rationale for using "rlibtool" and not "rclibtool" is extremely weak. It is based on midipix advocacy that is not actually technologically correct -- Gentoo already strips .la archives at the end of src_install and an ebuild that fails to do so because it was tested with slibtool is simply, plainly, unambiguously, an invalid ebuild. An ebuild must also work on systems that are configured to use GNU libtool. Because of this, the foundational logic by which midipix claims slibtool should not create .la archives is rendered invalid. --Eschwartz (talk) 00:33, 9 October 2024 (UTC)

Please refrain from misrepresenting users or user opinions based on what others claim they have or haven't said. The slibtool project was created in a context entirely unrelated to Gentoo by a person (myself) who in fact does not use Gentoo. There is no "advocacy", however many in the Gentoo community, including several maintainers, have expressed interest in slibtool, which resulted in a testing environment, the aforementioned wiki page, and several other discussions. --Midipix (talk) 12:41, 9 October 2024 (UTC)

slibtool does provide a mode where .la files are created and installed. If gcc fails to build without that then building gcc with rclibtool may indeed be a solution, although knowing the reason for why gcc actually fails would be a good thing, at least since older versions of gcc built perfectly fine with just rlibtool. Whether or not to use rclibtool by default in all of Gentoo ebuilds is a Gentoo internal matter. --Midipix (talk) 12:41, 9 October 2024 (UTC)

I think part of the confusion here is that the revert message for the wiki page referred to midipix upstream, but as you say, it's a Gentoo internal matter what we choose to support (we might even be more ambitious in future) or not. I think it's reasonable that, for the time being at least, we request people report bugs in Gentoo with rclibtool to focus on more obvious and less avoidable problems. I'll also say that a wiki page doesn't need to reflect upstream opinion anyway, but rather a compromise between what Gentoo supports, what upstream supports, and also what is practical wrt known bugs in packages. --Sam (talk) 19:56, 16 October 2024 (UTC)

At the risk of repeating myself, forcing this for all packages when its needed for only a few at most is silly. It would be better to force it for the specific packages only, that way it would be visible so someone could fix it. Its entirely possible to do this with package.env or someone could finish the eclass PR I made a while ago. As most of the packages that could use it were otherwise fixed I thought it was overkill at the time. --Orbea (talk) 14:00, 17 October 2024 (UTC)

I see no reason why the mode you propose is better - I still see it generating manifest files (after all, it'd be impossible not to), they're just not suffixed .la or formatted the same. You also refer to fixing, but nothing (except slibtool) is acting incorrectly here (and slibtool does it by design, hence the word "fixed" doesn't work)? I'm confused. Arsen (talk) 07:46, 26 October 2024 (UTC)

GNU libtool installs .la files by default which leads to many issues, hence this is why many distros now manually remove them inside their packages. As this behavior is not ideal slibtool has by design not installed them at all and this is working correctly. The fix would be to improve the GCC build system to not depend on this legacy behavior. Something which almost all packages already do. --Orbea (talk) 14:09, 9 October 2024 (UTC)

Regarding "GNU libtool installs .la files by default which leads to many issues", I know, that's why we delete them. Regarding "As this behavior is not ideal slibtool has by design not installed them at all and this is working correctly", that doesn't matter - GCC is fine with .la stripping, so it ought to be fine with a 'drop-in' replacement. Regarding "The fix would be to improve the GCC build system to not depend on this legacy behavior", this behaviour is not legacy, it is current, and it is not an improvement to add a workaround for incompatible implementations (see also: the history of internet explorer). I'm not sure what you mean by "Something which almost all packages already do". Note, also, that GCC does not use pure GNU libtool, so trying to replace it with a (not really) drop-in replacement that's meant to (but does not) act like GNU libtool is even more odd, given that replacing it with GNU libtool would also be iffy or broken. Knowing the patches applied on top of ~2008 libtool in the toolchain tree, I don't think this should be an issue, but I'd consider bug reports invalid on basis of that. Arsen (talk) 14:47, 26 October 2024 (UTC)

Slibtool has never aimed to be bug compatible with GNU libtool nor to emulate all of their poor design decisions. --Orbea (talk) 14:52, 9 October 2024 (UTC)

"nor to emulate all of their poor design decisions" -> then bug reports using it are invalid; thanks for confirming. Arsen (talk) 15:11, 26 October 2024 (UTC)

Perhaps you shouldn't act authoritative on a subject you clearly don't know much about? --Orbea (talk) 15:28, 9 October 2024 (UTC)

While the best solution is to fix gcc where upstream has been receptive to making changes for slibtool in the past when asked nicely, but alternatively the solution should to use rclibtool for only gcc when most other packages do not require it. Using it globally will only hide issues that can be fixed. It would be wrong to use the less than ideal mode when only a single package depends on it. --Orbea (talk) 13:47, 9 October 2024 (UTC)

AFAICT, this is the only generally compatible mode. I see no reason why packages should adjust to incompatible implementations. GCC isn't broken here, that mode of operation is. Arsen (talk) 07:46, 26 October 2024 (UTC)

This has already been explained, this "compatible mode" is only required for a extremely minimal number of packages which are relying on less than ideal behavior and where these packages could be improved to not do that. It would like be arguing that the entire system has to be compiled with -O1 because a handful of packages are broken with -O2. I would be happy to actively work on fixing slibtool issues again if my PRs could be reviewed in a reasonable time frame (I have several open atm) --Orbea (talk) 14:14, 9 October 2024 (UTC)

Regarding "It would like be arguing that the entire system has to be compiled with -O1 because a handful of packages are broken with -O2", please do not make false comparisons. Unlike O1 vs O2, slibtool, rlibtool and libtool _are not guaranteed to exhibit the same behavior_, it'd seem. slibtool does not do something libtool does, which programs are free to rely on, just like programs are free to rely on 1 + 1 = 2 in C in O1 and O2. Regarding "relying on less than ideal behavior", I see no reason why this is less than ideal. A less dishonest comparison would be O2 vs Ofast. Arsen (talk) 14:47, 26 October 2024 (UTC)

That is not at all dishonest, if you were to use -Ofast everywhere a lot more than a small handful of packages would likely break unlike -O2 which may break in a few rare examples. This has been a long standing behavior in Slibtool that works in almost all cases. I reiterate that if there is going to be a workaround it should be done for specific ebuilds so that these cases can be tracked. --Orbea (talk) 14:55, 9 October 2024 (UTC)

As slibtool is apparently not supposed to act the same as libtool, it cannot be analogized with O1 and O2. Arsen (talk) 15:11, 26 October 2024 (UTC)

The fact that there is a troubleshooting entry at all here is an embarrassment. Why should people want to use slibtool if it manifests in weird bugs that break your system? Gentoo should advise how to create a robust system. And Gentoo should refrain from offering documentation that steers people towards behavior that will result in them opening new bugs on bugs.gentoo.org which I will have to close with "go away, you're doing something silly and unsupported". Gentoo has a procedure for removing .la files when they are known to be unnecessary and this is not it. -- Eschwartz (talk) 23:32, 8 October 2024 (UTC)

I find that the tone of the above paragraph weakens both the quality and integrity of the original posting. --Midipix (talk) 12:41, 9 October 2024 (UTC)