I also mentioned this in #midipix @ freenode. Basically I understand this needs volunteer(s) other than @midipix.

Indeed, and perfectly agreed. I'd like to see this in the form of slibtool-test, having one set of tests that is implementation-neutral (testing against both slibtool and gnu libtool), and another set that targets slibtool's extra features.

We should aim at complete coverage of all valid (and invalid) combinations of flags and switches, and make sure all tests pass after each commit-candidate. Building third-party software as part of the test-suite is probably less desirable, however we could have a list of third-party software for building before a release, thereby increasing both reliability and coverage.

I know the ideal is a suite of unit tests, but building existing code is both 1) trivial and 2) useful. :)

https://github.com/rossburton/slibtool/blob/ci/.travis.yml is incredibly ghetto and minimal (doing CI in Travis via the GitHub mirror). It builds and installs slibtool, then tries to build/install libxml2.

Logs at https://travis-ci.com/github/rossburton/slibtool. Interestingly, it fails during libxml2 install:

make[4]: Entering directory '/home/travis/build/rossburton/libxml2-2.9.10/python'
rlibtool  --tag=CC   --mode=link gcc  -g -O2   -module -avoid-version ../libxml2.la   -L/usr/lib/python2.7/config-x86_64-linux-gnu -L/usr/lib -lpython2.7 -lpthread -ldl  -lutil -lm  -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions  -o libxml2mod.la -rpath /usr/lib/python2.7/dist-packages libxml.lo libxml2-py.lo types.lo  
rlibtool: link: x86_64-linux-gnu-ar crs .libs/libxml2mod.a .libs/libxml.o .libs/libxml2-py.o .libs/types.o
rlibtool: link: gcc .libs/libxml.o .libs/libxml2-py.o .libs/types.o -g -O2 -L../.libs -lxml2 -ldl -lz -llzma -lm -L/usr/lib/python2.7/config-x86_64-linux-gnu -L/usr/lib -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -Wl,-O1 -Wl,-Bsymbolic-functions -shared -fPIC -o .libs/libxml2mod.so -Wl,--export-dynamic
/usr/bin/ld: unrecognized option '-Wl,-O1'
/usr/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
rlibtool: exec error upon slbt_exec_link_create_library(), line 1446: (see child process error messages).
rlibtool: < returned to > slbt_exec_link(), line 1836.
Makefile:600: recipe for target 'libxml2mod.la' failed

For some reason, slibtool is passing -Wl,-O1 (a compiler flag) to ld.

I see you're building there from your own fork on github -- was it already on 0.5.31? Looks like the error is related to the 0.5.29 regression.

There's another issue there, btw., unrelated to the regression, looking at this now.

I see you're building there from your own fork on github -- was it already on 0.5.31? Looks like the error is related to the 0.5.29 regression.
There's another issue there, btw., unrelated to the regression, looking at this now.

Looking again, it appears that your fe4ef8eb0fdfe463a508e836d807f0723696f994 was based off of 0.5.31. We are not seeing the same error, though, and yours seems to be unrelated to slibtool:

make[4]: Entering directory '/home/travis/build/rossburton/libxml2-2.9.10/python'>

rlibtool --tag=CC --mode=link gcc -g -O2 -module -avoid-version ../libxml2.la -L/usr/lib/python2.7/config-x86_64-linux-gnu -L/usr/lib -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -o libxml2mod.la -rpath /usr/lib/python2.7/dist-packages libxml.lo libxml2-py.lo types.lo

=> the faulty -Wl,-O1 seems to be coming from the Makefile, and it could be that gnu libtool simply "swallows" it, turning this into a silent error. Can you verify that?

Issue #18 that was detected while building libxml2 with slibtool on a modern system has now been fixed. As things turned out, that issue had to do with proper -Xlinker support, and since -Xlinker happens to be the argument right before -export-dynamic -Wl,-O1, the failure you experienced with the travis build should be gone now. Please verify (against 2c4e5f9) and let us know!

Testing now.

That commit isn't on your GitHub, do you plan to mirror there or mark it obsolete?

Good news: 2c4e5f9 fixes the libxml2 build.

That commit isn't on your GitHub, do you plan to mirror there or mark it obsolete?

I suggest using this as the main repo. I think the github mirror is just for visibility.

https://git.foss21.org/slibtool

That commit isn't on your GitHub, do you plan to mirror there or mark it obsolete?

The github mirror is normally synchronized immediately, except for right now for completely mundane reasons... but even so, the authoritative git repository remains https://git.foss21.org/slibtool.

That commit isn't on your GitHub, do you plan to mirror there or mark it obsolete?

Btw. for you own work-in-progress fork, you could also create one here (https://dev.midipix.org), however if the main objective of your github fork is travis then let's talk about what a standard post-commit build might entail. Your comment above regarding the advantages in building third-party packages was well taken and I'm open to adding travis integration to the repository.

Following discussion on irc: currently leaning towards --mode=probe, which in my opinion has the following advantages:

1. allows developers to test against arbitrary toolchains and arbitrary sets of cflags/ldflags.

2. allow end-users to easily test against the build settings of a build project in a trivial way, i.e:
   $ rlibtool --mode=probe (for those who miss old times and the dreaded self-test mode:=))

3. running of tests as an slibtool feature rather than a separate package