On Tuesday 31 May 2011 12:31:36, Simon Marlow wrote:

...

The ticket has low priority, but if anybody has an idea how to check whether libbfd depends on libz in the configure script, I'd appreciate it.

Could you install a shared version of libbfd?

I have one, $ locate libbfd /home/dafis/.deps/libbfd.Plo /usr/lib/libbfd-2.20.0.20100122-6.so /usr/lib/libbfd.a /usr/lib/libbfd.la The problem is, as far as I can tell, that a) libbfd.a is picked up instead of the .so in the first place, and b) that both depend on libz: $ ldd /usr/lib/libbfd-2.20.0.20100122-6.so linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0xb743e000) libc.so.6 => /lib/libc.so.6 (0xb72d3000) /lib/ld-linux.so.2 (0xb76fd000) There's # Libraries that this one depends upon. dependency_libs=' -lz' in libbfd.la, and the inflate* symbols are undefined in libbfd*.

Failing that, the easiest thing to do would be to make a test that compiles a program depending on libbfd and if it fails to link, just disable HAVE_LIBBFD (it's no great loss).

I'm far from an expert, but as far as I can see, there is already such a test, in configure.ac: AC_CHECK_LIB(bfd, bfd_init) with a test using bfd_init in configure. Unfortunately, that doesn't detect if libz is needed without using some functions depending on it. If I had the slightest idea how to make it detect the dependency on libz, I happily would, but I've not yet found any introduction to shell scripting or using autotools accessible to a complete beginner.

Cheers, Simon

On Tuesday 31 May 2011 14:44:58, Simon Marlow wrote:

What you need is libbfd.so, which is a symbolic link to the versioned library (libbfd-2.20.0.20100122-6.so). This is normally installed by the development version of the library (e.g. libbfd-dev on Debian-derived distros).

Couldn't find anything like that for openSuSE (11.3), the versioned .so comes with binutils, libbfd.a (and .la) come from binutils-devel. I'll take a look at the AC stuff and if I don't see how it might work, I'll try with a manually created symlink.

The shared version has the dependency built-in, so the GHC build system wouldn't have to do anything (that's how it works here).

...

I'm far from an expert, but as far as I can see, there is already such a test, in configure.ac:

AC_CHECK_LIB(bfd, bfd_init)

I think that only tests for the presence of the symbol in the library, it doesn't test that compiling an executable against that library actually works.

Well, compiling and running a simple test programme that calls bfd_init() works here without linking in libz, so I guess that test wouldn't detect the dependency even if it actually runs the executable.

...

with a test using bfd_init in configure. Unfortunately, that doesn't detect if libz is needed without using some functions depending on it. If I had the slightest idea how to make it detect the dependency on libz, I happily would, but I've not yet found any introduction to shell scripting or using autotools accessible to a complete beginner.

Yes, I'm afraid the learning curve is a bit steep. It's so hard to get right that I wouldn't even attempt to try to fix it without a machine to test on! A good place to start would be tests that do similar things - a quick look at the code suggests AC_COMPILE_IFFELSE and AC_LINK_IFFELSE might be useful, also FP_CHECK_FUNC looks like it might do what you want.

I'll look. Cheers, Daniel

On Tuesday 31 May 2011 16:04:28, Simon Marlow wrote:

On 31/05/2011 14:53, Daniel Fischer wrote:

...

Well, compiling and running a simple test programme that calls bfd_init() works here without linking in libz, so I guess that test wouldn't detect the dependency even if it actually runs the executable.

That's very mysterious. Perhaps bfd_init doesn't pull in anything that has the libz dependency,

That's what I think.

and you have to call some other function in the bfd library instead. Here's a fragment of code in the RTS that calls bfd functions:

bfd_init(); abfd = bfd_openr(name, "default"); if (abfd == NULL) { barf("can't open executable %s to get symbol table", name); } if (!bfd_check_format_matches (abfd, bfd_object, &matching)) { barf("mismatch"); }

calling bfd_openr alone produces tons of undefined references, I've no idea what libraries I'd have to link with also :(

Cheers, Simon

On Tuesday 31 May 2011 16:39:19, Donn Cave wrote:

Quoth Daniel Fischer , ...

...

calling bfd_openr alone produces tons of undefined references, I've no idea what libraries I'd have to link with also :(

Try -lbfd -liberty -lz ?

Donn

Thanks. That worked. Without a symlinked libbfd.so in /usr/lib, linking failed without -lz, programme successfully ran when linked with -lz; With a symlink, -lz wasn't even needed (and no undefined reference.. failures in the testsuite either). It seems the linker looks for libbfd.so first, if that isn't found, it falls back on libbfd.a which needs -lz. So basically, it's an openSuSE bug, I'd say. Nevertheless, having a test would be good. Unfortunately, looking at configure.ac and configure didn't give me any idea how to do it yet. Cheers, Daniel

On 01/06/2011 02:55, Daniel Fischer wrote:

On Tuesday 31 May 2011 16:04:28, Simon Marlow wrote:

...

That's very mysterious. Perhaps bfd_init doesn't pull in anything that has the libz dependency, and you have to call some other function in the bfd library instead.

Not having a better idea, I replaced bfd_init in the AC_CHECK_LIB with bfd_uncompress_section_contents, because that one definitely pulls in the libz dependency. And it worked for me™.

Without libbfd-version.so symlinked to libbfd.so, the test failed to link, hence there was no #define HAVE_LIBBFD 1 written to confdefs.h, no link failures due to the libz dependency in the testsuite.

With the symlink, the test linked, #define HAVE_LIBBFD 1 was written to confdefs.h, no link failures due to the libz dependency in the testsuite.

Unless there's a reason that change would break things elsewhere, it'd be a simple fix.

Great, will do. Cheers, Simon