Bug#340942: Can't actually use libcurl?
Hi David,
On Tue, Nov 29, 2005 at 08:31:20AM -0500, David Roundy wrote:
On Mon, Nov 28, 2005 at 11:55:46PM -0800, Steve Langasek wrote:
Yes, curl-config is messed up in the sense that curl-config is *always*
messed up for purposes of dynamic linking on GNU systems. In the present
case, curl-config spits out -lkrb5 and other library options, but is
missing a dependency on libkrb5-dev. This is bug #340784, and should be
fixed reasonably soon.
On the darcs side, this is fixable by changing the Debian package to not
use curl-config -- as described at
http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html.
It's understandable that upstream would not want to accept such a patch,
since it's not portable to platforms which use non-GNU linkers; but for
Debian's purposes, until curl-config adds a --static option to split
these other garbage linker options out, it's far better to replace
`curl-config --libs` with -lcurl as this is much less likely to lead to
future build failures as a result of curl bugs.
Is there some sort of autoconf trickery we could use upstream to check if
the gnu linker is present and fall back on curl-config if it isn't?
Hmm, interesting question. Following the autoconf principle of test for
features, not for platforms, I would probably do something like this:
AC_DEFUN([CHECK_SHARED_LIBS],[
AC_LANG_PUSH([C])
AC_LANG_CONFTEST([
int liba_dosomething() {
return 0;
}
])
if $CC -shared -o libconftest-a.so conftest.$ac_ext
then
[AC_LANG_CONFTEST([
extern int liba_dosomething();
int libb_dosomething() {
return liba_dosomething();
}
])
if $CC -shared -o libconftest-b.so conftest.$ac_ext -L. -lconftest-a
then
save_LDFLAGS=$LDFLAGS
LDFLAGS=$LDFLAGS -L.
save_LIBS=$LIBS
LIBS=-lconftest-b
AC_LINK_IFELSE([
AC_LANG_PROGRAM([extern int libb_dosomething();],
[return libb_dosomething();])
],[ac_gnu_style_elf=yes],[ac_gnu_style_elf=no])
LIBS=$save_LIBS
LDFLAGS=$save_LDFLAGS
else
ac_gnu_style_elf=no
fi
else
ac_gnu_style_elf=no
fi
rm conftest* libconftest*
AC_LANG_POP
])
And then you could add CHECK_SHARED_LIBS to configure.in and check the value
of $ac_gnu_style_elf afterwards; but there are some problems with this
approach, such as losing any -L options provided by curl-config. If I were
you, I would just put pressure on curl upstream to split the curl-config
output between --libs and --libs --static, so you can make it their problem
to sort out what the correct flags are for a given platform. :)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Bug#340942: Can't actually use libcurl?
severity 340942 important thanks On Mon, Nov 28, 2005 at 06:35:15PM -0800, Isaac Jones wrote: David Roundy [EMAIL PROTECTED] writes: (snip) ... It would help to have the config.log. Most likely the curl-config output is messed up in some way. We use curl-config to determine which flags to use to link with curl, but then we check whether these flags actually work, and it is this check that fails. So either curl-config is messed up (as it used to be on MacOS--it claimed to be x86) or our test is misfunctioning in some way. It could be that our workaround for the bug in curl-config on MacOS is somehow backfiring on another platform... :( Yes, curl-config is messed up in the sense that curl-config is *always* messed up for purposes of dynamic linking on GNU systems. In the present case, curl-config spits out -lkrb5 and other library options, but is missing a dependency on libkrb5-dev. This is bug #340784, and should be fixed reasonably soon. On the darcs side, this is fixable by changing the Debian package to not use curl-config -- as described at http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html. It's understandable that upstream would not want to accept such a patch, since it's not portable to platforms which use non-GNU linkers; but for Debian's purposes, until curl-config adds a --static option to split these other garbage linker options out, it's far better to replace `curl-config --libs` with -lcurl as this is much less likely to lead to future build failures as a result of curl bugs. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#340942: Can't actually use libcurl?
On Mon, Nov 28, 2005 at 11:55:46PM -0800, Steve Langasek wrote: Yes, curl-config is messed up in the sense that curl-config is *always* messed up for purposes of dynamic linking on GNU systems. In the present case, curl-config spits out -lkrb5 and other library options, but is missing a dependency on libkrb5-dev. This is bug #340784, and should be fixed reasonably soon. On the darcs side, this is fixable by changing the Debian package to not use curl-config -- as described at http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html. It's understandable that upstream would not want to accept such a patch, since it's not portable to platforms which use non-GNU linkers; but for Debian's purposes, until curl-config adds a --static option to split these other garbage linker options out, it's far better to replace `curl-config --libs` with -lcurl as this is much less likely to lead to future build failures as a result of curl bugs. Is there some sort of autoconf trickery we could use upstream to check if the gnu linker is present and fall back on curl-config if it isn't? -- David Roundy http://www.darcs.net signature.asc Description: Digital signature
Bug#340942: Can't actually use libcurl?
David Roundy [EMAIL PROTECTED] writes: (snip) ... It would help to have the config.log. Most likely the curl-config output is messed up in some way. We use curl-config to determine which flags to use to link with curl, but then we check whether these flags actually work, and it is this check that fails. So either curl-config is messed up (as it used to be on MacOS--it claimed to be x86) or our test is misfunctioning in some way. It could be that our workaround for the bug in curl-config on MacOS is somehow backfiring on another platform... :( David, It fails in the same way on most Debian architecture that the autobuilders attempted (see bottom): http://buildd.debian.org/build.php?pkg=darcs It didn't fail on my personal machine, and I'm trying to figure that out now. The autobuilders didn't attempt to build it for i386 since they already had the binary that I built. peace, isaac -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
