Forum: GNU Radio compile failure of svn head with slightly old install

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
5e81c66258333eb8e665cc4814d0a6d5?d=identicon&s=25 Greg Troxel (Guest)
on 2007-02-24 00:32
(Received via mailing list)
I updated and tried to build the head of svn recently after not having
done so for several weeks.  The block code failed to build,
complaining about several pmt_foo functions not being found.   I did a
'make -k install' from top level, and then it built fine.  So it seems
that the build is linking against installed libs rather than in-tree
libs.

I'm of two minds here, becaues I think it's very important that we be
able to build components by themselves against installed libraries.
So, probabaly the build should use -L for the build tree and then also
the installed path, in that order.
Cec0a4bf0e0575f3a3171892e6097e59?d=identicon&s=25 Johnathan Corgan (Guest)
on 2007-02-24 00:38
(Received via mailing list)
Greg Troxel wrote:

> I updated and tried to build the head of svn recently after not having
> done so for several weeks.  The block code failed to build,
> complaining about several pmt_foo functions not being found.   I did a
> 'make -k install' from top level, and then it built fine.  So it seems
> that the build is linking against installed libs rather than in-tree
> libs.

On my main development system (Linux Ubuntu 6.10), I normally do a 'make
uninstall' to clean out the system directories of related libraries, .py
files, .h files, etc.  Then I do a 'make distclean' inside the tree, to
remove all the old cruft.   Only then do I do the usual ./bootstrap,
./configure, etc.

I've done this twice today on the trunk with no problems, and once with
the release 3.0 branch, including 'make distcheck'.

Not sure what's happening in your situation--can you try the above?

--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-02-24 01:17
(Received via mailing list)
On Fri, Feb 23, 2007 at 05:27:45PM -0500, Greg Troxel wrote:
> I updated and tried to build the head of svn recently after not having
> done so for several weeks.  The block code failed to build,
> complaining about several pmt_foo functions not being found.   I did a
> 'make -k install' from top level, and then it built fine.  So it seems
> that the build is linking against installed libs rather than in-tree
> libs.

The build tree should be linking against the build tree
(non-installed) libs.

> I'm of two minds here, becaues I think it's very important that we be
> able to build components by themselves against installed libraries.
> So, probabaly the build should use -L for the build tree and then also
> the installed path, in that order.

I understand your goal, but that's not how we're currently doing it.
If you've got a suggestion (and a patch) to handle this robustly both
ways, I'm willing to entertain it.

What I want to be sure that we can do is to run make check against the
non-installed libraries prior to installation.

Is NetBSD using a vanilla version of libtool, or a modified version?

At least under GNU/Linux the unmodified libtool does what I expect
(supports testing against non-installed libs), and relinks against the
install path as part of installation.  The Ubuntu folks have patched
libtool in a way that breaks the ability to test before installing.
Putting it mildly, I think they're out of their minds ;)

Eric
5e81c66258333eb8e665cc4814d0a6d5?d=identicon&s=25 Greg Troxel (Guest)
on 2007-02-24 04:57
(Received via mailing list)
Eric Blossom <eb@comsec.com> writes:

> The build tree should be linking against the build tree
> (non-installed) libs.

I agree, and pretty clearly it wasn't.

> I understand your goal, but that's not how we're currently doing it.
> If you've got a suggestion (and a patch) to handle this robustly both
> ways, I'm willing to entertain it.

Entirely reasonable.

> What I want to be sure that we can do is to run make check against the
> non-installed libraries prior to installation.
>
> Is NetBSD using a vanilla version of libtool, or a modified version?

pkgsrc has a slightly modified version, but it seems to be only
patches for various platforms that haven't been merged upstream for
various reasons.  I'm aware of no intent to behave oddly on purpose.

Jonathan Corgan wrote:

  On my main development system (Linux Ubuntu 6.10), I normally do a
'make
  uninstall' to clean out the system directories of related libraries,
.py
  files, .h files, etc.  Then I do a 'make distclean' inside the tree,
to
  remove all the old cruft.   Only then do I do the usual ./bootstrap,
  ./configure, etc.

I did make uninstall, clean, make and it built.  But I'd say it's a
bug if you have to uninstall first.



I can't trivially reproduce this first, but it seems to be mblock's
use of pmt that's troublesome.  This could be just the only user of
functions that changed signature, though.
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-02-24 09:25
(Received via mailing list)
On Fri, Feb 23, 2007 at 10:56:34PM -0500, Greg Troxel wrote:
>   ./configure, etc.
>
> I did make uninstall, clean, make and it built.  But I'd say it's a
> bug if you have to uninstall first.

Agreed.  I'm not in the habit of uninstalling, unless I'm trying to
confirm that an install on a virgin machine is working.


> I can't trivially reproduce this first, but it seems to be mblock's
> use of pmt that's troublesome.  This could be just the only user of
> functions that changed signature, though.

If anything, I suspect problems with how we're specifying
inter-library dependencies.  Since this used to work under NetBSD and
now has a problem, I'm suspicious of a couple of changes that
recently went in that were supposed to fix something related to
library dependencies on Cygwin/MinGW.

Eric
821c1adf3f4be2f2aa6fbc89cce4c69a?d=identicon&s=25 Michael Dickens (Guest)
on 2007-02-24 15:27
(Received via mailing list)
On Feb 23, 2007, at 7:20 PM, Eric Blossom wrote:
> The build tree should be linking against the build tree
> (non-installed) libs.

This was the issue I came up against when working on the 3.0 release
branch recently - I had a previous install of the GR trunk to which
the current compile was trying to link.  Since the 3.0 release
doesn't "know" about libgromnithread, while the trunk relies upon it,
the branch wouldn't compile since it was trying to link against non-
built tree libraries.  Once I removed the trunk's install everything
went OK ... I really have no idea it was still around, since I had
already "uninstall"ed it but apparently some of the files didn't get
removed by the uninstaller. - MLD
This topic is locked and can not be replied to.