Re: [Discuss-gnuradio] libtool/linker/dynamic loader stuff

[Eric Blossom]

On Sun, Feb 25, 2007 at 08:58:25AM -0500, Greg Troxel wrote:
> That sounds good to me, but if we're talking a major change,

Hopefully, this isn't a major change.  I'm thinking that it's a bug
fix and the creation of developer documentation that says exactly how
we're linking everything and why.

I believe that the recent breakage is a result of some "fixes" for win32.


> I'd like to throw out something somewhere between desire and requirement:
> 
>   If a component A is enabled, but a GNU Radio component B that is a
>   dependency for A is not enabled (by configure), then build and make
>   check both use the installed version of B.
> 
> This property is needed in order to be able to build separate packages
> for separate parts of GNU Radio, or at least to do so reasonably.

Seems like a reasonable request.

> Berndt: can you comment on whether this works ok now?  If so, can you
> explain how/why?
> 
> I'll also comment that some systems, including the BSDs, use -R (or
> -rpath) to encode the search path for dependencies in executables and
> libraries.
>
> This is different from the Linux use of a global path, and
> the resulting apparently not infrequent use of LD_LIBRARY_PATH.
> It is also different from the Mac OS X way of encoding full paths for
> dependencies.  I think libtool deals with this correctly.
> 
> It is likely that if all works ok on NetBSD that it will also be ok on
> OpenBSD and FreeBSD.

Good.

> I think GNU Radio largely has the desired properties already, but not
> quite.  I believe that having a linker search path that looks in the
> build tree and then the installed system at build time, and that then
> avoids the build tree when final installation happens is sufficient.
> It may be that there is a -lfoo instead of libfoo.la in a Makefile
> now.

I believe that's the current problem.  We used to always use
libfoo.la.  There was a recent change that added -lfoo in addition to
libfoo.la.

Eric