Hi Ralf,
On Fri, 13 Jan 2006, Ralf Wildenhues wrote: > Hi Gary, > > * Gary Kumfert wrote on Thu, Jan 12, 2006 at 09:07:52PM CET: > > > > I'm learning that libtool 1.5.22 "fixed" the -static flag so that > > static libraries are linked in the build directory, but > > shared libraries in the install directory. But I don't > > understand why this is considered "better" behavior. > > The discussion was controversial: > http://thread.gmane.org/gmane.comp.gnu.libtool.general/6573 > http://thread.gmane.org/gmane.comp.gnu.libtool.patches/5636 > and references therein. > > > The side-effect is that libtool behaves very > > differently between "make check" and "make installcheck" > > ...particularly in my case, since the libraries being linked > > have #ifdef PIC preprocessor directives in their source. > > Yep. Not very nice. Matches the documentation though, and the > pre-1.5 behavior of libtool, quoting (Link mode): > | `-static' > | If OUTPUT-FILE is a program, then do not link it against any > | uninstalled shared libtool libraries. If OUTPUT-FILE is a > | library, then only create a static library. So, you changed behavior that's been established for years only because the documentation and code differed? Wouldn't it have been easier to just fix the documentation? > > I thought the -all-static flag would be a solution, but it > > seems to go too far... trying to link in *every* library (even > > system libraries) statically. > > glibc (and other libs that dlopen modules internally) protest > > vociferously on the link line (how do they do that?) and > > ultimately break my build. > > Yep, I see that in quite a few cases, too. Also, link_static_flag is > not correctly determined for some systems (we have a TODO item about > that). > > > I'm at the point of hacking in my own -lt-static flag to > > reproduce the old behavior of -static.... but first I wanted > > to do a sanity check. > > > > 1. Am I the only one who prefers the older behavior? > > See above. > > > 2. Is there another way to make just the libtool libraries static > > after they've been installed? > > I don't understand this question. What is the reason that prevented you > from creating just a static library for these ones in the first place? Yes, I suppose I didn't give enough information to motivate why I want to do what I do... I was hoping there was some "undocumented" backward compatibility feature. I'm going to fudge a bunch of details to keep this email short, but essentially I have two kinds of libraries: implementations and proxies. libXXX_impl.{a,so} has the real implementation of some software components, and they could be in any language (C,C++,Fortran,Python,Java,etc.) Langauge-specific proxies are required to make calls on these components. These proxies are generally useful, so we also put these in libraries, say libXXX_proxy_c.{a,so}. To support both dynamic loading and static linking of the impls, proxies have "#ifdef PIC" regions in them to behave two different ways. If they're static libraries, PIC isn't #defined, and they directly reference symbols in libXXX_impl.a assuming it too is statically linked. If they're shared libraries, PIC is defined, and they make no direct reference to symbols in libXXX_impl.so, but instead dlopen the module. Now, when I do "make installcheck" with the new libtool behavior, the drivers for static tests should be linked against the libXXX_stub_c.a & libXX_impl.a. Instead it gets linked against libXXX_stub_c.so which wants to dlopen things, but isn't given the RPATH, so it fails. > > 3. Could there be an alternative way to structure the libraries? > > I haven't yet fully grasped your needs. A couple of questions in > return: > > - Would it be sufficient if libtool implemented per-deplib > `-Bstatic/-Bdynamic' (whatever they're called) switches? I can imagine this may be useful (you can never have too much control when you really need it), but its unnecessarily complex for my immediate needs. Generally, our users either want all dynamic-loaded modules for flexibility (&access from interpreted languages), or all static for speed. > - The former is not so easy to implement, so: as an easier measure, > were the former 1.5.x semantics of `-static' exactly those you > needed? Maybe we should just implement another option to get > those semantics again, as you suggested above. I wouldn't name > it `-lt-static' though. Maybe `-static-libtool-libs' would fit > better, but it's rather long. Yes. I think this would be fine. I'll leave it to you to pick the name. I'm only going to write it once in a sed command to my Makefiles. Thanks, Gary _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
