Eric Blossom wrote:
>> 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.
This was done to fix ticket 138 on Win32 platf
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
That sounds good to me, but if we're talking a major change, 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 ins
It seems like it's time to fully revist the interlibrary dependency
issue, and the related issue of reliably and robustly testing with
build tree libs vs install tree libs.
My priority order for this working is:
Free systems are first priority:
* GNU/Linux must work as expected using unmoles
