[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#221420: libtool: deletes test coverage files when linking

From: Scott James Remnant
Subject: Re: Bug#221420: libtool: deletes test coverage files when linking
Date: Sat, 22 Nov 2003 10:34:18 +0000

(Cc to bug-libtool incase others have some ideas)

On Tue, 2003-11-18 at 08:02, Andrew Suffield wrote:

> I have a source file foo.c, which I compile to foo.lo, and then link
> into foo.la (the name prefixes have to match to trigger the bug).
I bet you don't really, I bet your C file begins with 'lib' and is
called (at least) libfoo.c.  You can't have a .la file which name
doesn't begin with 'lib' after all <g>.

> If I compile with -ftest-coverage, then .libs/foo.bb and .libs/foo.bbg
> are created by gcc, which contain the basic block traces needed for
> gcov to work.

> When I then link foo.la, libtool blithely deletes foo.bb and foo.bbg.
> This is the offending chunk of code:
>       if test "$mode" != relink; then
>       # Remove our outputs, but don't remove object files since they
>       # may have been created when compiling PIC objects.
>       removelist=
>       tempremovelist=`$echo "$output_objdir/*"`
>       for p in $tempremovelist; do
>         case $p in
>           *.$objext)
>              ;;
>           $output_objdir/$outputname | $output_objdir/$libname.* | 
> $output_objdir/${libname}${release}.*)
>              removelist="$removelist $p"
>              ;;
>           *) ;;
>         esac
>       done
>       if test -n "$removelist"; then
>         $show "${rm}r $removelist"
>         $run ${rm}r $removelist
>       fi
>       fi
> It assumes that .libs/$libname.*, other than $libname.$objext, should
> be removed. This is, uh, wrong. I have no idea why it's doing this or
> what it should do instead.
I imagine it's doing it because working out what random files the linker
is going to create alongside is tricky, and perhaps non-determinate.  Or
maybe just that the author of that code was feeling lazy, of course.

The only way I can think of would be to either increase the list of
specific excludes there, ie. don't remove .bb and .bbg[0], or to change
it to removing only specific files.


[0] suggest a name for a variable to hold a list of non-linker file
    extensions, someone!
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]