bug-libtool
[Top][All Lists]
Advanced

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

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


From: Gary V. Vaughan
Subject: Re: Bug#221420: libtool: deletes test coverage files when linking
Date: Mon, 24 Nov 2003 12:24:59 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 Thunderbird/0.3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott James Remnant wrote:
| (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>.

pkgexeclib_LTLIBRARIES = foo.la
foo_la_LDFLAGS = -module
foo_la_SOURCES = foo.c

|>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.
|>
|
| Right...
|
|
|>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.

precious_files_regex, which is `\.${objext}$' by default, but which the user
can extend with a new `-precious-regex' option?...

Just thinking aloud.

Cheers,
        Gary.
- --
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://www.oranda.demon.co.uk
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/wfibFRMICSmD1gYRAvCfAJ9klgwWSwKUZ7xOhCNngRCARYZrIQCfTCh4
px+M3BR2x30p5tqT28AxCwI=
=wUeL
-----END PGP SIGNATURE-----





reply via email to

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