Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support for static libraries #11

jtpalmer opened this Issue Apr 22, 2012 · 7 comments


None yet
4 participants

jtpalmer commented Apr 22, 2012

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 commented Apr 23, 2012

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 commented Aug 30, 2014

@jtpalmer, feel like helping out on this?


jtpalmer commented Aug 30, 2014

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 commented Aug 30, 2014

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 commented Sep 1, 2014

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 commented Sep 11, 2014

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.

@plicease plicease closed this Sep 11, 2014


mohawk2 commented Sep 12, 2014

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

@plicease plicease referenced this issue in run4flat/Alien-TinyCC Nov 3, 2014


shared version of libtcc.a (libtcc.so) #6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment