-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config-scripts: Fix --enable-libtool-unsupported #394
Conversation
When the LIBTOOL variable is set in the user's environment the build will use libtool even when --enable-libtool-unsupported is not used. This can lead to unexpected failures when LIBTOOL is set to rlibtool rather than GNU libtool. To solve this the build now relies on the enable_libtool_unsupported varaiable set by --enable-libtool-unsupported. Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=843638
@michaelrsweet When you have a chance I would really appreciate if you could review this PR to see if this suggestion is more acceptable? |
@orbea I am attending the PWG/OpenPrinting meeting all week, so I may not get a chance to review and test this until the end of the week... |
No worries, thank you for letting me know. |
@michaelrsweet Would you be able to take a look and let us know if this is in the right direction? This is one of the last few big packages in Gentoo which can't be built with slibtool as-is, so going over the remaining bugs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so this looks basically correct but why the enable_shared=no
? The whole point of using libtool is to make it possible to create shared libraries on platforms that we don't explicitly support.
@michaelrsweet I'm not sure why its there, but its already present in the build path with libtool enabled and I only moved the lines. cups/config-scripts/cups-libtool.m4 Lines 17 to 18 in 02c6a72
|
Ah, I did some digging and the libtool support automatically creates both static and shared libraries so we disable the CUPS build system's shared library support and treat the libtool generated libraries as "static". |
Thanks for looking into that. Either way my goal with this change was to make enabling the libtool build more explicit and not cause unexpected issues with slibtool in Gentoo where I intentionally tried to not change any behavior for the libtool build in cups. |
When building cups with LIBTOOL=rlibtool exported in make.conf the build will fail. This happens because slibtool can't determine build information from the generated libtool script that doesn't exist. Its better to just not use libtool at all in this build system. Bug: https://bugs.gentoo.org/843638 Upstream-PR: OpenPrinting/cups#394 Signed-off-by: orbea <orbea@riseup.net>
When building cups with LIBTOOL=rlibtool exported in make.conf the build will fail. This happens because slibtool can't determine build information from the generated libtool script that doesn't exist. Its better to just not use libtool at all in this build system. Bug: https://bugs.gentoo.org/843638 Upstream-PR: OpenPrinting/cups#394 Signed-off-by: orbea <orbea@riseup.net> Closes: #25431 Signed-off-by: Sam James <sam@gentoo.org>
Alternative fix for PR #392.
Also see comment #392 (comment).
When the LIBTOOL variable is set in the user's environment the build will use libtool even when --enable-libtool-unsupported is not used.
This can lead to unexpected failures when LIBTOOL is set to rlibtool rather than GNU libtool.
To solve this the build now relies on the enable_libtool_unsupported varaiable set by --enable-libtool-unsupported.
Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=843638