liborange 0.4: "broken" libtool scripts?

Discussion:

Evgeni Golov

2009-02-04 11:50:14 UTC

Hi,

I'm the Debian maintainer of orange and wanted to update the packages
to the current 0.4 release. While doing so, I noticed a annoying
breakage compared to the old 0.3.2 release:
building/linking liborange.so.0.0.0 does not honour LDFLAGS (it works
for the orange binary well).

I'm setting LDFLAGS="-Wl,-z,defs -Wl,--as-needed" in my build scripts,
so the resulting package has less dependencies and thus does not need
rebuilds when some other library changes. For orange that is libdbus
and libhal, which libsynce is linked against. When now libhal would
change it's soname, one only need to rebuild libsynce and not
liborange which does not use libhal directly (but gets linked against
it, because libsynce is). But as liborange does not honour my LDFLAGS,
it gets a dependency on libhal and would need a rebuild too.

I did some digging and came to the following:
1. liborange 0.4 with ltmain.sh and aclocal.m4 from the old 0.3.2
release honours the LDFLAGS fine and the resulting library isnt linked
against libdbus/libhal.
2. liborange 0.4 from SVN with ltmain.sh and aclocal.m4 generated by
the bootstrap script on my Debian Sid box does also honour the LDFLAGS.
3. Only the released version with no changes does not.

Can you reproduce this by building liborange with
LDFLAGS="-Wl,-z,defs -Wl,--as-needed"
and running
objdump -x liborange.so.0.0.0 |grep NEEDED
on the resulting .so?

What can we do for this?
1. Upload to Debian in the current state.
I'd like not to, because I'd like to have the list of direct
dependencies as small as possible.
2. Upload 0.4 with changed ltmain.sh/aclocal.m4.
Possible, but one usually wants to have the diff to the original
upstream release as small as possible.
3. You release 0.4.1 with fixed scripts.
IMHO the best way, as here everyone would have the benefit of less
direct dependencies, not only Debian/Ubuntu.

TIA & kind regards
Evgeni Golov

Mark Ellis

2009-02-04 15:26:46 UTC

Permalink

Post by Evgeni Golov
Hi,
I'm the Debian maintainer of orange and wanted to update the packages
to the current 0.4 release. While doing so, I noticed a annoying
building/linking liborange.so.0.0.0 does not honour LDFLAGS (it works
for the orange binary well).

I'm guessing this has something to do with the libtool version, I'm on
2.2.4. Evgeni, what version are you ?

I'm open to suggestions on how to fix it, but frankly libtool is a black
box to me.

Post by Evgeni Golov
I'm setting LDFLAGS="-Wl,-z,defs -Wl,--as-needed" in my build scripts,
so the resulting package has less dependencies and thus does not need
rebuilds when some other library changes. For orange that is libdbus
and libhal, which libsynce is linked against. When now libhal would
change it's soname, one only need to rebuild libsynce and not
liborange which does not use libhal directly (but gets linked against
it, because libsynce is). But as liborange does not honour my LDFLAGS,
it gets a dependency on libhal and would need a rebuild too.
1. liborange 0.4 with ltmain.sh and aclocal.m4 from the old 0.3.2
release honours the LDFLAGS fine and the resulting library isnt linked
against libdbus/libhal.
2. liborange 0.4 from SVN with ltmain.sh and aclocal.m4 generated by
the bootstrap script on my Debian Sid box does also honour the LDFLAGS.
3. Only the released version with no changes does not.
Can you reproduce this by building liborange with
LDFLAGS="-Wl,-z,defs -Wl,--as-needed"
and running
objdump -x liborange.so.0.0.0 |grep NEEDED
on the resulting .so?
What can we do for this?
1. Upload to Debian in the current state.
I'd like not to, because I'd like to have the list of direct
dependencies as small as possible.
2. Upload 0.4 with changed ltmain.sh/aclocal.m4.
Possible, but one usually wants to have the diff to the original
upstream release as small as possible.
3. You release 0.4.1 with fixed scripts.
IMHO the best way, as here everyone would have the benefit of less
direct dependencies, not only Debian/Ubuntu.
TIA & kind regards
Evgeni Golov
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel

Mark Ellis

2009-02-04 15:43:24 UTC

Permalink

Post by Mark Ellis

I'm guessing this has something to do with the libtool version, I'm on
2.2.4. Evgeni, what version are you ?

Heh, thats 1.5.26 from Debian sid here.

Post by Mark Ellis
I'm open to suggestions on how to fix it, but frankly libtool is a black
box to me.

Same here :(

In fact, I can see the flags being passed in the build.

/bin/bash ../libtool --tag=CC --mode=link gcc -Wall -Wsign-compare
-Wno-long-long -Wall -no-undefined -version-info 0:0:0 -Wl,-z,defs
-Wl,--as-needed -o liborange.la
-rpath /home/mark/sources/synce/tmp/test-2/lib dllinflate.lo extract.lo
helper.lo installshield_sfx.lo liborange_log.lo nullsoft.lo pe.lo
rsrc.lo separate.lo squeeze.lo suf.lo tomtom.lo -lsynce -ldynamite
-lunshield -lz -lmagic

libtool: link: gcc
-shared .libs/dllinflate.o .libs/extract.o .libs/helper.o .libs/installshield_sfx.o
.libs/liborange_log.o .libs/nullsoft.o .libs/pe.o .libs/rsrc.o .libs/separate.o
.libs/squeeze.o .libs/suf.o .libs/tomtom.o /usr/lib/libsynce.so
-L//lib -L/usr/lib -lhal -ldbus-glib-1
-ldbus-1 /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so
-lm /usr/lib/libdynamite.so /usr/lib/libunshield.so /usr/lib/libmagic.so
-lz -Wl,-z -Wl,defs -Wl,--as-needed -Wl,-soname -Wl,liborange.so.0
-o .libs/liborange.so.0.0.0

so I really have no idea whats going on.

Mark

Mark Ellis

2009-02-05 10:41:57 UTC

Permalink

Post by Mark Ellis

I'm guessing this has something to do with the libtool version, I'm on
2.2.4. Evgeni, what version are you ?

Heh, thats 1.5.26 from Debian sid here.

Post by Mark Ellis
I'm open to suggestions on how to fix it, but frankly libtool is a black
box to me.

Same here :(

In fact, I can see the flags being passed in the build.

So can I.
flags are passed but ignored. Revert to 1.5.26, rerun ./bootstrap and
everything is fine.
Any chance to stick to 1.x for orange?

I'd rather not, just because I'd have to remember it was manually
installed etc etc

However, I'm making progress :)

Looking at the command line again...

libtool: link: gcc
-shared .libs/dllinflate.o .libs/extract.o .libs/helper.o .libs/installshield_sfx.o
.libs/liborange_log.o .libs/nullsoft.o .libs/pe.o .libs/rsrc.o .libs/separate.o
.libs/squeeze.o .libs/suf.o .libs/tomtom.o /usr/lib/libsynce.so
-L//lib -L/usr/lib -lhal -ldbus-glib-1
-ldbus-1 /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so
-lm /usr/lib/libdynamite.so /usr/lib/libunshield.so /usr/lib/libmagic.so
-lz -Wl,-z -Wl,defs -Wl,--as-needed -Wl,-soname -Wl,liborange.so.0
-o .libs/liborange.so.0.0.0

then looking at the ld man page

--as-needed
--no-as-needed
This option affects ELF DT_NEEDED tags for dynamic libraries
mentioned on the command line after the --as-needed option. Normally,
the linker will add a......

Aha !

Run that command manually with -Wl,--as-needed before all the libs and
it works !

But the flags are being passed to libtool before the dependency libs,
and for some reason libtool thinks it's a good idea to move them to the
end.

Now to figure out why.

Mark Ellis

2009-02-06 09:45:35 UTC

Permalink

Post by Mark Ellis
However, I'm making progress :)
Looking at the command line again...
libtool: link: gcc
-shared .libs/dllinflate.o .libs/extract.o .libs/helper.o .libs/installshield_sfx.o
.libs/liborange_log.o .libs/nullsoft.o .libs/pe.o .libs/rsrc.o .libs/separate.o
.libs/squeeze.o .libs/suf.o .libs/tomtom.o /usr/lib/libsynce.so
-L//lib -L/usr/lib -lhal -ldbus-glib-1
-ldbus-1 /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so
-lm /usr/lib/libdynamite.so /usr/lib/libunshield.so /usr/lib/libmagic.so
-lz -Wl,-z -Wl,defs -Wl,--as-needed -Wl,-soname -Wl,liborange.so.0
-o .libs/liborange.so.0.0.0
then looking at the ld man page
--as-needed
--no-as-needed
This option affects ELF DT_NEEDED tags for dynamic libraries
mentioned on the command line after the --as-needed option. Normally,
the linker will add a......
Aha !
Run that command manually with -Wl,--as-needed before all the libs and
it works !

Yes and no.
Yes it works, but it worked with the late --as-needed in 0.3.2 too. So
thats prolly not the problem here.
And btw, here at Debian, libtool is patched not to do such insane
things like reoderings of the arguments :)
But the gcc -shared ... line still looks like your above, and the deps
are stripped. Go figure.
I guess the 2.2 scripts fetch some deps from
libsynce.la and dont know they can strip those, while 1.5 knows that.

It's all a bit heavy really :(

I've dropped a line to the libtool mailing list for help. I'd like to
figure out what's going on, since this will be happening with all the
new packages.

Mark

Evgeni Golov

2009-02-06 07:44:24 UTC

Permalink

--
Bruce Schneier Fact Number 404:
It is thought that Bruce Schneier lives on a hidden sub-basement level
deep under Fort Meade.

Evgeni Golov

2009-02-04 18:42:14 UTC

Permalink

Post by Mark Ellis

I'm guessing this has something to do with the libtool version, I'm on
2.2.4. Evgeni, what version are you ?

Heh, thats 1.5.26 from Debian sid here.

Post by Mark Ellis
I'm open to suggestions on how to fix it, but frankly libtool is a black
box to me.

Same here :(

In fact, I can see the flags being passed in the build.

So can I.

Now I tried with libtool 2.2.6a and have exactly the bad behaviour:
flags are passed but ignored. Revert to 1.5.26, rerun ./bootstrap and
everything is fine.

Any chance to stick to 1.x for orange?

--
Bruce Schneier Fact Number 140:
Bruce Schneier tampers with tamperproof hardware.

Evgeni Golov

2009-02-04 15:34:17 UTC

Permalink

Post by Mark Ellis

I'm guessing this has something to do with the libtool version, I'm on
2.2.4. Evgeni, what version are you ?

Heh, thats 1.5.26 from Debian sid here.

Post by Mark Ellis
I'm open to suggestions on how to fix it, but frankly libtool is a black
box to me.

Same here :(

--
Bruce Schneier Fact Number 134:
The phonograph record included on the Voyager probe contains a hidden
watermark inserted by Bruce Schneier.