inflateInit?

inflateInit?

[DJ Delorie]

Two of my simulators (so far) are failing thusly:

gcc -DHAVE_CONFIG_H     -DPROFILE=1 -DWITH_PROFILE=-1   -DWITH_DEFAULT_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_TARGET_WORD_BITSIZE=32 -DWITH_TARGET_WORD_MSB=31 -DWITH_TARGET_BYTE_ORDER=LITTLE_ENDIAN    -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DDEFAULT_INLINE=0   -DWITH_RESERVED_BITS=1    -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized    -DDEBUG -I/sata/dj/gnu/gdb/src/sim/v850/../../newlib/libc/sys/sysnecv850   -I. -I/sata/dj/gnu/gdb/src/sim/v850 -I../common -I/sata/dj/gnu/gdb/src/sim/v850/../common -I../../include -I/sata/dj/gnu/gdb/src/sim/v850/../../include -I../../bfd -I/sata/dj/gnu/gdb/src/sim/v850/../../bfd -I../../opcodes -I/sata/dj/gnu/gdb/src/sim/v850/../../opcodes  -g -O2 -o run \
	  nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a  ../../libiberty/libiberty.a -lnsl  
../../bfd/libbfd.a(compress.o): In function `bfd_uncompress_section_contents':
/sata/dj/gnu/gdb/src/bfd/compress.c:96: undefined reference to `inflateInit_'
/sata/dj/gnu/gdb/src/bfd/compress.c:103: undefined reference to `inflate'
/sata/dj/gnu/gdb/src/bfd/compress.c:106: undefined reference to `inflateReset'
/sata/dj/gnu/gdb/src/bfd/compress.c:108: undefined reference to `inflateEnd'
collect2: ld returned 1 exit status
make[3]: *** [run] Error 1
make[3]: Leaving directory `/sata/dj/gnu/gdb/v850-elf/sim/v850'

Are we partway through adding -lz to everything?

Re: inflateInit?

[Daniel Jacobowitz]

Redirecting to binutils and Craig; I assume this is his patch from
yesterday.

I'm just guessing, but I bet everything that uses libbfd but not
libtool is going to be broken by this change.

On Thu, Jul 10, 2008 at 11:18:01AM -0400, DJ Delorie wrote:
> 
> Two of my simulators (so far) are failing thusly:
> 
> gcc -DHAVE_CONFIG_H     -DPROFILE=1 -DWITH_PROFILE=-1   -DWITH_DEFAULT_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_TARGET_WORD_BITSIZE=32 -DWITH_TARGET_WORD_MSB=31 -DWITH_TARGET_BYTE_ORDER=LITTLE_ENDIAN    -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DDEFAULT_INLINE=0   -DWITH_RESERVED_BITS=1    -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized    -DDEBUG -I/sata/dj/gnu/gdb/src/sim/v850/../../newlib/libc/sys/sysnecv850   -I. -I/sata/dj/gnu/gdb/src/sim/v850 -I../common -I/sata/dj/gnu/gdb/src/sim/v850/../common -I../../include -I/sata/dj/gnu/gdb/src/sim/v850/../../include -I../../bfd -I/sata/dj/gnu/gdb/src/sim/v850/../../bfd -I../../opcodes -I/sata/dj/gnu/gdb/src/sim/v850/../../opcodes  -g -O2 -o run \
> 	  nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a  ../../libiberty/libiberty.a -lnsl  
> ../../bfd/libbfd.a(compress.o): In function `bfd_uncompress_section_contents':
> /sata/dj/gnu/gdb/src/bfd/compress.c:96: undefined reference to `inflateInit_'
> /sata/dj/gnu/gdb/src/bfd/compress.c:103: undefined reference to `inflate'
> /sata/dj/gnu/gdb/src/bfd/compress.c:106: undefined reference to `inflateReset'
> /sata/dj/gnu/gdb/src/bfd/compress.c:108: undefined reference to `inflateEnd'
> collect2: ld returned 1 exit status
> make[3]: *** [run] Error 1
> make[3]: Leaving directory `/sata/dj/gnu/gdb/v850-elf/sim/v850'
> 
> Are we partway through adding -lz to everything?
> 

-- 
Daniel Jacobowitz
CodeSourcery

Re: inflateInit?

[Craig Silverstein]

} Redirecting to binutils and Craig; I assume this is his patch from
} yesterday.

Yes it is, I'm sorry for the trouble.

I have code in the configure script for bfd that checks for the
existence of zlib (and zlib.h); if it doesn't find it, it turns off
the code in compress that you're running into.

It looks like that didn't work for you for some reason?  Can you attach
your config.log script, that you got from building libbfd?  Also, the
contents of your bfd-directory config.h would be helpful.

Oh, come to think of it, all that is probably working properly.  The
issue looks to be that you're using libbfd.a instead of libbfd.so.
The .so has appropriate settings so that when you link against it,
it also pulls in libz.so (at least, as I understand how .so's work;
DT_NEEDED or something?)  But .a's don't have that.  I don't know
what the principled solution is -- have libbfd.a bring in libz.a, or
what -- but one solution that should work in the short term is to
just add libz.a to your link line.


craig

Re: inflateInit?

[DJ Delorie]

> what -- but one solution that should work in the short term is to
> just add libz.a to your link line.

I'm more interested in fixing this the right way, as mine are
automated builds.  Is there a --disable-compression option for bfd/gdb
(gdb calls it too) that we can use, or perhaps make the default until
we fix this?

Re: inflateInit?

[Craig Silverstein]

} I'm more interested in fixing this the right way, as mine are
} automated builds.

But you control the Makefile for them, right?  Every place where
you're specifying libbfd.a right now, you can just change it to
   libbfd.a -lz
(or "libbfd.a /usr/lib/libz.a", or whatever the appropriate location
for you is).

} Is there a --disable-compression option for bfd/gdb (gdb calls it
} too) that we can use, or perhaps make the default until we fix this?

Hmm, not at the moment, but you're right it may be a good idea to add
it.

craig

Re: inflateInit?

[DJ Delorie]

> } I'm more interested in fixing this the right way, as mine are
> } automated builds.
> 
> But you control the Makefile for them, right?

No.  The build cleans out any non-cvs-pristine sources and checks out
the latest, then runs configure, make, etc.  If it's not in CVS it's
not going to make it into my builds.  If I added it to CVS (assuming I
had permission to do so), then any system missing libz would break.

Besides, "you should hack your Makefiles" is not a suitable solution
to this kind of problem.  I'm not the only one trying to build them.

Re: inflateInit?

[Daniel Jacobowitz]

On Thu, Jul 10, 2008 at 03:23:35PM -0400, DJ Delorie wrote:
> 
> > } I'm more interested in fixing this the right way, as mine are
> > } automated builds.
> > 
> > But you control the Makefile for them, right?
> 
> No.  The build cleans out any non-cvs-pristine sources and checks out
> the latest, then runs configure, make, etc.  If it's not in CVS it's
> not going to make it into my builds.  If I added it to CVS (assuming I
> had permission to do so), then any system missing libz would break.
> 
> Besides, "you should hack your Makefiles" is not a suitable solution
> to this kind of problem.  I'm not the only one trying to build them.

GDB is safe from this particular error, because it already uses zlib.
I think the only thing we can do is add equivalent autoconf tests for
zlib to other things which link to BFD but do not use libtool.
Mostly, that means the sim.

-- 
Daniel Jacobowitz
CodeSourcery

Re: inflateInit?

[Craig Silverstein]

} I think the only thing we can do is add equivalent autoconf tests
} for zlib to other things which link to BFD but do not use libtool.

A hack I've done for this kind of thing in the past is to use weak
symbols.  The idea is that we have a weak definition of inflate(),
defined in bfd/compress.c, that is a noop.  If you link in zlib, you
get the real inflate, otherwise you use the weak inflate.

I know it's a hack, and a non-portable one, and may not work in any
case if you link in libz.a instead of libz.so.  But I could add it in
if folks thought it was worthwhile.

But I agree easiest is to clean up the sim.  It sounds like it's
discouraged for folks to use libbfd directly, so this may not be such
a widespread issue.

craig

Re: inflateInit?

[Craig Silverstein]

} Besides, "you should hack your Makefiles" is not a suitable solution
} to this kind of problem.  I'm not the only one trying to build them.

I'm sorry if I wasn't clear: I was suggesting you fix the Makefile and
then check it in to whatever source control system you're using.

} If I added it to CVS (assuming I had permission to do so), then any
} system missing libz would break.

But such a system wouldn't have the compression stuff built into
libbfd either, so you'd be fine.  You can just use the same configure
rule for your project that bfd uses for its:
   AC_SEARCH_LIBS(zlibVersion, z, [AC_CHECK_HEADERS(zlib.h)])

As long as you build your project and libbfd at the same time, which
as I understand it is pretty much a requirement when working with
libbfd, then everything should work.

craig

Re: inflateInit?

[Hans-Peter Nilsson]

On Thu, 10 Jul 2008, Craig Silverstein wrote:

> But I agree easiest is to clean up the sim.  It sounds like it's
> discouraged for folks to use libbfd directly, so this may not be such
> a widespread issue.

I'll clean this up, please don't try unless you really build all
sims...

brgds, H-P

Re: inflateInit?

[Craig Silverstein]

} I'll clean this up, please don't try unless you really build all
} sims...

Great! -- thanks for your help.

craig

Re: inflateInit?

[H.J. Lu]

On Thu, Jul 10, 2008 at 5:55 PM, Craig Silverstein <csilvers@google.com> wrote:
> } I'll clean this up, please don't try unless you really build all
> } sims...
>
> Great! -- thanks for your help.
>
> craig
>

Hi Craig,

"make check" in ld fails on Linux/ia32 and Linux/x86-64:

http://sourceware.org/bugzilla/show_bug.cgi?id=6741

Could you please fix it?

Thanks.


-- 
H.J.

Re: inflateInit?

[Craig Silverstein]

} "make check" in ld fails on Linux/ia32 and Linux/x86-64:
} http://sourceware.org/bugzilla/show_bug.cgi?id=6741
} Could you please fix it?

Yep, I'm on it.  Sorry for the trouble.

craig

Re: inflateInit?

[H.J. Lu]

On Sat, Jul 12, 2008 at 12:36 PM, Craig Silverstein <csilvers@google.com> wrote:
> } "make check" in ld fails on Linux/ia32 and Linux/x86-64:
> } http://sourceware.org/bugzilla/show_bug.cgi?id=6741
> } Could you please fix it?
>
> Yep, I'm on it.  Sorry for the trouble.
>
> craig
>

Hi Craig,

Your patch caused another regression:

http://sourceware.org/bugzilla/show_bug.cgi?id=6743

Could you please fix it?

Thanks.

-- 
H.J.

Re: inflateInit?

[Craig Silverstein]

} Your patch caused another regression:
} http://sourceware.org/bugzilla/show_bug.cgi?id=6743
} Could you please fix it?

I'll look into it now.  Sorry for the trouble.  If you can come up
with a simple testcase that tests this (I had trouble coming up with a
good addr2line test, since results are so architecture dependent),
I'll add it to the testsuite so something like this doesn't happen
again.

craig

Re: inflateInit?

[H.J. Lu]

On Sun, Jul 13, 2008 at 12:33 PM, Craig Silverstein <csilvers@google.com> wrote:
> } Your patch caused another regression:
> } http://sourceware.org/bugzilla/show_bug.cgi?id=6743
> } Could you please fix it?
>
> I'll look into it now.  Sorry for the trouble.  If you can come up
> with a simple testcase that tests this (I had trouble coming up with a
> good addr2line test, since results are so architecture dependent),
> I'll add it to the testsuite so something like this doesn't happen
> again.
>

Here is one:

./addr2line -e ./addr2line `nm  -n  --defined-only  ./addr2line  |head
-1 | awk '{print $1}'`

But it may not abort on all platforms.


-- 
H.J.

Re: inflateInit?

[Craig Silverstein]

} ./addr2line -e ./addr2line `nm  -n  --defined-only  ./addr2line  |head
} -1 | awk '{print $1}'`

Yes, it works on all the ones I've tested on.  I'm still trying to
reproduce the problem you reported.

craig

Re: inflateInit?

[H.J. Lu]

On Sun, Jul 13, 2008 at 3:57 PM, Craig Silverstein <csilvers@google.com> wrote:
> } ./addr2line -e ./addr2line `nm  -n  --defined-only  ./addr2line  |head
> } -1 | awk '{print $1}'`
>
> Yes, it works on all the ones I've tested on.  I'm still trying to
> reproduce the problem you reported.
>
> craig
>

Some glibc, like the one in Fedora 9, will check invalid pointers passed to
free by default.  If you use Linux, you can try

[hjl@gnu-26 binutils]$ MALLOC_CHECK_=1 ./addr2line -e ./addr2line `nm
-n  --defined-only  ./addr2line |head -1 | awk '{print $1}'`
malloc: using debugging hooks
??:0
*** glibc detected *** free(): invalid pointer: 0x0000002a95734d53 ***
[hjl@gnu-26 binutils]$


-- 
H.J.