I've found a way to get treedb et al building again.
Basically I dropped the do-nothing-but-drag-in-dependent libs.
M4, pkg-config and automake can simply push new variable values, so it's almost
seamless.
I triggered a g++-4.6 miscompilation
On 06/14/2011 06:06 PM, Philip Ashmore wrote:
I've found a way to get treedb et al building again.
Basically I dropped the do-nothing-but-drag-in-dependent libs.
M4, pkg-config and automake can simply push new variable values, so it's
almost
seamless.
I triggered a g++-4.6
On 14/06/11 17:31, Matthias Klose wrote:
On 06/14/2011 06:06 PM, Philip Ashmore wrote:
I've found a way to get treedb et al building again.
Basically I dropped the do-nothing-but-drag-in-dependent libs.
M4, pkg-config and automake can simply push new variable values, so it's almost
seamless.
Hi there.
Thanks for your feedback, Jonathan.
I am as confused as ever, which I think is down to the medium we're using
(text).
For me this is actually good news, as I'm going to use this as the basis for a
new storyboard story (storyboard is a project of mine), where I'll try to
explain
my
On 09/06/11 05:53, Jonathan Nieder wrote:
Why would libtool follow the static-link model when linking to a DSO?
Seehttp://bugs.debian.org/191425. If you disagree with the
reasoning mentioned in that bug and the bugs it is merged with, that
would be a libtool (behavior or documentation) bug.
Philip Ashmore wrote:
I know that libtreedb.so, or one of its dependants, exports needed symbols.
Whether I link
directly or indirectly, that symbol will end up in the address space of the
executable.
That was never portable. Checking the Makefile for git (which is
the example I have at
I see what you mean. But that's from the perspective of binutils.
It works in a schroot I set up that uses only the stock Squeeze repos,
so to me it looks like an ld/automake problem.
Or was it that I was inadvertently using a loop-hole to do something
automake didn't intend?
I'm pretty sure
Besides, @treedb_BARE_LIBS@ @v3c_LIBS@ expands to
${top_builddir}/v3c/libtreedb-0.9-bare.la -lpthread -L/usr/lib
-Wl,-rpath -Wl,/usr/lib -lv3c-1.8 -luuid
so that's not going to work.
Matthias, have you tried reproducing the problem as I've outlined it above?
Philip
--
To UNSUBSCRIBE, email
Philip Ashmore wrote:
It works in a schroot I set up that uses only the stock Squeeze repos,
so to me it looks like an ld/automake problem.
Not all behavior changes are bugs. :) As mentioned before, the
default in ld changed to --no-copy-dt-needed-entries for wheezy.
I'm pretty sure that it
Package: binutils
Version: 2.21.51.20110523-1
Severity: normal
I've just uploaded v3c-1.8.2-02.
It builds just fine.
treedb-0.9.2-01, however isn't so fortunate.
You'll need to download both from SourceForge
http://sourceforge.net/projects/v3c/
http://sourceforge.net/projects/treedb/
I've put
Hi Philip,
Philip Ashmore wrote:
The reason for this bug report is because of what happens in
build/v3c/2-cartwheel -
a show stopper.
libtool: link: gcc -g -ggdb -O0 -Wall -Wextra -Werror -Wformat -fno-strict-
aliasing -pthread -o .libs/allocator-test-16
Jonathan Nieder wrote:
Philip Ashmore wrote:
/usr/bin/ld: note: 'v3c_native_endian_index' is defined in DSO
/v3c/dev/autobook/treedb/build/v3c/.libs/libtreedb-0.9-bare.so.902 so try
adding it to the linker command line
This part sounds like the --no-copy-dt-needed-entries change --- see
On 06/07/2011 08:58 AM, Philip Ashmore wrote:
Package: binutils
Version: 2.21.51.20110523-1
Severity: normal
I've just uploaded v3c-1.8.2-02.
It builds just fine.
treedb-0.9.2-01, however isn't so fortunate.
You'll need to download both from SourceForge
http://sourceforge.net/projects/v3c/
retitle 629498 ld.bfd: could not read symbols: Invalid operation after
indirect reference is unhelpful
# cosmetic
severity 629498 minor
tags 629498 + upstream
quit
Philip Ashmore wrote:
/usr/bin/ld: allocator_test_16-allocator-test.o: undefined reference to
symbol 'v3c_native_endian_index'
14 matches
Mail list logo
