Support for static libraries

[jtpalmer]

Just a thought, but is there a reason static libraries aren't supported. I've been looking at a couple non-Alien::Base Alien:: modules and they specifically only build static libraries. I might be wrong, but static libraries would not need the need run-time provision mentioned in the documentation. This is advantageous since the Alien module would no longer be a run-time requirement.

[jberger]

There really isn't a major reason, one of the biggest is that I really am not proficient in the compiler-linker stuff (or C in general), so I am doing what I can. Someone had mentioned that there are issues with using static libraries too, I'm not sure exactly what those are. Honestly I'm for whatever works in the end. Most of the select/fetch/build phases are independent of this anyway and that was what I was good at; we are seeing my limitations now.

[mohawk2]

@jtpalmer, feel like helping out on this?

[jtpalmer]

I haven't been following Alien::Base development as closely as I was, so I don't think I'd be much help at this point. Have you already discussed anything with @jberger ? I think the issues I was experiencing may have been resolved.

[plicease]

Two challenges with this are

1. build libraries with position independent code on platforms that require it (not usually the default when creating a static library)
2. force the linker to choose the static library when linking the Foo.so file

For autotool packages the first can be accomplished by passing --with-pic option to configure.

For the linker there are three approaches that I can think of

1. Come up with the correct linker flags to prefer the static library. This is very tricky and not very portable.
2. Disable shared libraries during the build. Sometimes this is supported by packages but you can't count on it depending on the package (even if the --help says shows the option). Also I'd like to see shared libraries built so they can be used by FFI modules (as with Alien::Libarchive::FFI).
3. after running make install segregate the dll files so they are no longer in the library search path. I did this by moving .so, .dll and .dylib files into a dll directory.

This is tricky to fix at the Alien::Base level since the configure command line is specified in the caller at the moment, but possibly some tools could be built into AB to make it easier?

[plicease]

One advantage of using static libraries is that Foo::XS does not need to use Alien::Foo at runtime (only at install) since the dynamic library path doesn't need to be adjusted.

This also works nicely in that Alien::Foo (and Alien::Base) become build dependencies which can reduce the number of packages that need to be installed if you are using rpms or .debs.

[plicease]

With the new alien_isolate_dynamic property it is now possible to get static libraries with Alien::Base. The big caveat here is that some platforms require position independent code, which is generated by default on autotool style packages that support --with-pic. If there are easy ways to get other build systems to behave in this way we can add support for them as well.

[mohawk2]

For me the key goal is to make things work, regardless of ideas of "elegance". Let us keep pressing forward, making things work!