Original issue: https://github.com/midipix-project/slibtool/issues/11
Opened by: ghost (User deleted)

ghost commented on Aug 20, 2018:

Hi, everyone! I'm very interested at slibtool. Can I use this as FULL libtool replacement? If yes what I should to do with slibtool. What symlinks I need to make and etc.

Thanks!

midipix commented on Aug 21, 2018:

the short answer is yes: for all of its supported flavors (linux,bsd,midipix,cygwin,mingw), slibtool should work out of the box for both native- and cross-compilations (but see note concerning ar(1) below). In the common scenario involving ./configure && make && make install, one could simply:

$ export MAKE="make LIBTOOL=rlibtool"
$ make LIBTOOL=rlibtool

At the next level, you may instruct make(1) to use slibtool by default via the MAKEFLAGS environment variable:

$ export MAKEFLAGS='LIBTOOL=rlibtool'

A small, temporary limitation concerning native builds only, is that your path needs to provide a target-specific symlink to the native ar. The symlink could be easily created by running the following command as root:

$ ln -s ar /usr/bin/$(cc -dumpmachine)-ar

With slibtool 0.5.27 and later, however, the above symlink should no longer be necessary.

ghost commented on Aug 21, 2018:

Can export LIBTOOL variable to the profile?
…
On Tue, Aug 21, 2018, 1:14 PM midipix @.*> wrote: the short answer is yes: for all of its supported flavors (linux,bsd,midipix,cygwin,mingw), slibtool should work out of the box for both native- and cross-compilations (but see note concerning ar(1) below). In the common scenario involving ./configure && make && make install, one could simply: $ export MAKE="make LIBTOOL=rlibtool" $ make LIBTOOL=rlibtool At the next level, you may instruct make(1) to use slibtool by default via the MAKEFLAGS environment variable: $ export MAKEFLAGS='LIBTOOL=rlibtool' A small, temporary limitation concerning native builds only, is that your path needs to provide a target-specific symlink to the native ar. The symlink could be easily created by running the following command as root: $ ln -s ar /usr/bin/$(cc -dumpmachine)-ar With slibtool 0.5.27 and later, however, the above symlink should no longer be necessary. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AZS_I4-0FVrqSboL_h7uXAlCYaQaqFFyks5uS92TgaJpZM4WEezO .

midipix commented on Aug 21, 2018:

That alone won't work, as what is required is not an environment variable, but rather a make(1) variable. What you could do, however, is export MAKEFLAGS as illustrated above, i.e.

export MAKEFLAGS=LIBTOOL=rlibtool

ghost commented on Aug 22, 2018:

Can I make rlibtool symlink to libtool? And what about libtoolize?
…
On Tue, Aug 21, 2018, 10:43 PM midipix @.***> wrote: That alone won't work, as what is required is not an environment variable, but rather a make(1) variable. What you could do, however, is export MAKEFLAGS as illustrated above, i.e. export MAKEFLAGS=LIBTOOL=rlibtool — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AZS_IyP_EL8o8dne6wESplNeZJPvUR_yks5uTGLRgaJpZM4WEezO .

midipix commented on Aug 22, 2018:

The above would be meaningless, but perhaps what you meant was turning /usr/bin/libtool into a symlink to slibtool (or rlibtool) -- which unfortunately would be meaningless as well, since the libtool which make(1) invokes at build time is not the "stock" libtool (i.e. /usr/bin/libtool) but rather a configuration-specific libtool script that's generated by a project's ltmain.sh as one of the last steps of ./configure.

ghost commented on Aug 22, 2018:

Okay. What about libtoolize?
…
On Wed, Aug 22, 2018, 8:51 PM midipix @.***> wrote: The above would be meaningless, but perhaps what you meant was turning /usr/bin/libtool into a symlink to slibtool (or rlibtool) -- which unfortunately would be meaningless as well, since the libtool which make(1) invokes at build time is not the "stock" libtool (i.e. /usr/bin/libtool) but rather a configuration-specific libtool script that's generated by a project's ltmain.sh as one of the last steps of ./configure. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AZS_IyLl6uYGy1KOzfqjGZiMO0DsUlskks5uTZoZgaJpZM4WEezO .

midpix commented on Aug 22, 2018:

Implementing a libtoolize drop-in replacement as part of slibtool sounds like a really interesting idea. As with slibtool, the best course of action would involve someone who's familiar with the original tool as a user and willing to test the replacement tool as it's being written. If the above is something you'd consider doing then please join the #midipix freenode irc channel.

ghost commented on Aug 22, 2018:

Okay. Thanks for info. Have nice day!
…
On Thu, Aug 23, 2018, 12:17 AM midipix @.***> wrote: Implementing a libtoolize drop-in replacement as part of slibtool sounds like a really interesting idea. As with slibtool, the best course of action would involve someone who's familiar with the original tool as a user and willing to test the replacement tool as it's being written. If the above is something you'd consider doing then please join the #midipix freenode irc channel. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AZS_I7M-qyF3RWw3D5oAFaBbSE2Ei3lLks5uTcp4gaJpZM4WEezO .

ghost commented on Aug 23, 2018:

So I found some libtoolize implementation https://github.com/libertine-linux-packages/slibtool/blob/master/filesystem/usr/bin/libtoolize
…
On Thu, Aug 23, 2018, 2:00 AM Nagakamira @.> wrote: Okay. Thanks for info. Have nice day! On Thu, Aug 23, 2018, 12:17 AM midipix @.> wrote: > Implementing a libtoolize drop-in replacement as part of slibtool sounds > like a really interesting idea. As with slibtool, the best course of action > would involve someone who's familiar with the original tool as a user and > willing to test the replacement tool as it's being written. If the above is > something you'd consider doing then please join the #midipix freenode irc > channel. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#11 (comment)>, > or mute the thread > https://github.com/notifications/unsubscribe-auth/AZS_I7M-qyF3RWw3D5oAFaBbSE2Ei3lLks5uTcp4gaJpZM4WEezO > . >

midipix commented on Aug 23, 2018:

Thanks for the reference. For all I can tell, a surrogate libtoolize would simply need to produce an empty ltmain.sh, which will then be added to the end of the libtool script generated by configure. Should that indeed be the case, I'd implement slibtoolize inside of slibtool (which already have the needed parsing primitives) and make slibtoolize a symlink to slibtool. Furthermore, the recursion option does not seem hard to implement, at least not in a naive way (simply look for all sub-directories containing a file named configure.ac with LT_INIT in it).

midipix commented on Nov 2, 2018:

As a quick follow up, I am still happy to implement (s)libtoolize, but would prefer to do so in collaboration with a (seasoned) user of libtoolize as a tester. If still interested in the above, please join the #midipix freenode irc channel and let me know.

orbea commented on Dec 20, 2018:

@midipix I am also interested in this. The current situation here is that while I don't use libtool much, the libtool package contains other things like libtoolize which are required for generating configure and the makefiles with a project specific autogen.sh or with autoreconf -fi.

I am not sure how replacing libtoolize would look in a way that doesn't break existing tools, but I have a lot of real world examples I can test if you want to work on this, ping me on irc if so. :)

RJVB commented on Feb 14, 2019:

What's the difference between rlibtool and slibtool?

orbea commented on Feb 14, 2019:

slibtool will build both shared and static libraries where rlibtool is a symlink to slibtool which has the behavior of automatically determining to build shared and/or static libraries based on configure arguments like --enable-shared or --enable-static.

There is also slibtool-shared and slibtool-static to force building only shared or static libraries.

RJVB commented on Feb 14, 2019:

I take it that you still get the thing you asked for via configure if you just use slibtool? The source shows that rlibtool activate heuristics mode, so my assumption must be correct (if we all have the same, correct interpretation of "heuristics" ;) )

orbea commented on Feb 14, 2019:

I take it that you still get the thing you asked for via configure if you just use slibtool?

No slibtool, slibtool-shared and slibtool-static ignored the relevant configure arguments and the user had to specifically choose which one to use. This was a big problem with libreoffice which needs both at different points of the build process which is when rlibtool was made. It now should be the default used by users except for a few cases. For example a program that is using $(LIBTOOL), but not autotools.

RJVB commented on Feb 14, 2019:

Well, then someone doesn't know what heuristics means ;) From what you describe, slibtool does heuristics while rlibtool does what the user instructed via configure. Or they both do, and we still have cross fingers that rlibtool actually makes the right guesses, possibly because the intended library type isn't indicated via an argument? (How does the libtool script know what to do in this situation?)

midipix commented on Feb 14, 2019:

No need for finger-crossing. In an autoconf-based project, the final step of configure is to have ltmain.sh generate a build-specific libtool script based on the arguments that were passed to configure plus whatever the project's (not slibtool's) configure was able to detect.

The heuristics performed by rlibtool are to (1) find the build-specific libtool script, which might reside in either the current directory or in a directory containing it, and (2) parse the above libtool script and determine whether shared and/or static libraries should be built.

midipix commented on Feb 14, 2019 :

For additional context: whether to build share and/or static libraries is hard-coded into each and every generated libtool script. To see the difference between slibtool and rlibtool in a "live" setting try this:

```

/some/autoconf/project/configure --disable-shared

./libtool --features

rlibtool --features

slibtool --features

```

Output from rlibtool and ./libtool should be identical, whereas slibtool should normally have both shared and static libraries enabled.

RJVB commented on Feb 14, 2019:

(2) parse the above libtool script and determine whether shared and/or static libraries should be built.
Oh, so you do that? Then it should only be a relatively small step to extract the AR and RANLIB executables from it, too, no?

firasuke referenced this issue in glaucuslinux/glaucus on Dec 18, 2019
Add slibtool to system cerata
https://github.com/glaucuslinux/glaucus/commit/b43e6733f693882ee530528fc542083a6e09d20a

firasuke commented on Mar 28:

Any updates on slibtoolize and sltdl?

midipix commented on Mar 29:

Core functionality of sltdl already works, so at this point I'd suggest that you give it a try and report anything that either is missing or does not work as expected.

slibtoolize is still in the works.

firasuke commented on Mar 29:

I see.

I was actually using libtool alongside slibtool to provide the rest of the functionality, but then I decided to rely on slibtool and found these two slibtoolize implementations:

1- Libertine's slibtoolize:
https://github.com/libertine-linux-packages/slibtool/blob/master/filesystem/usr/bin/libtoolize

2- Ataraxia's slibtoolize (a slightly modified version of Libertine's that fixes installation paths for ltmain.sh and the auxiliary build tools):
https://github.com/ataraxialinux/ataraxia/blob/master/stuff/slibtool/libtoolize

but the thing is, I didn't find it as a complete replacement for libtool.

We still need to rely on the macros provided by libtool and its ltmain.sh, as well as the auxiliary build tools provided by automake like depcomp, missing, install-sh...

I reverted back to libtool alone until slibtool is viable enough to replace the entirity of libtool.

midipix commented on Mar 29:

With respect to slibtoolize, you are right about the fact that the solutions you have found (from Libertine and Ataraxia) are incomplete, and that a full integration, where slibtoolize would supply alternate .m4 macros and other necessary files, is both preferable and required.

Please keep in mind, however, that slibtoolize should only be needed when you build from a raw soure tree, where upstream does not already provide you with ./configure and ./Makefile.in.

orbea commented on Mar 29:

Please keep in mind, however, that slibtoolize should only be needed when you build from a raw soure tree, where upstream does not already provide you with ./configure and ./Makefile.in.

I just want to point out that I often run autoreconf -fi even when a project includes such files to ensure that everything works. Additionally broken projects sometimes require patching the configure.ac and/or Makefile.am files which requires running autoreconf to take effect.

firasuke commented on Mar 29:

I just want to point out that I often run autoreconf -fi even when a project includes such files to ensure that everything works. Additionally broken projects sometimes require patching the configure.ac and/or Makefile.am files which requires running autoreconf to take effect.

This is exactly why I've reverted to libtool for now as it seems that these autoreconf, ./autogen.sh, ./bootstrap.sh and ./autogen.sh like scripts seem to always require stuff that will either need libtool to be provided alongside slibtool to cover for it (the macros and ltmain.sh mainly), or libtool to be used solely.

midipix commented on Mar 29:

True, and yet another reason to complete work on slibtoolize as quickly as possible...