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.
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?
On Fri, Feb 23, 2007 at 05:27:45PM -0500, Greg T. 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
On Fri, Feb 23, 2007 at 10:56:34PM -0500, Greg T. 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.
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
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
