libtool-patches
[Top][All Lists]
Advanced

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

Re: Partial linking of .lo objects, rev 2 (CVS HEAD)


From: Ralf Wildenhues
Subject: Re: Partial linking of .lo objects, rev 2 (CVS HEAD)
Date: Fri, 5 May 2006 05:54:10 +0200
User-agent: Mutt/1.5.11+cvs20060403

Hi Marc,

* Marc Alff wrote on Fri, May 05, 2006 at 04:51:30AM CEST:
> Ralf Wildenhues wrote:
> > * Marc Alff wrote on Sun, Apr 09, 2006 at 06:10:35PM CEST:
> >   
> >> - takes into account all the comments to date,
> >> - defines functional tests (compile, link, inspect the resulting binary)
> >> - uses Autotest
> >
> > Good.  It's probably ok to merge all the tests into one file, and
> > simplify them somewhat.
> 
> All the tests in one file may be a bit extreme, especially considering
> that some tests need to be run or skipped depending
> on the platform (static and shared might not be always supported), but
> some merging and simplification will be better.
> I will look into that.

Thanks.  You may be right that there should be more than one file and
test; I'd try to merge those which have lots of overlap though.

> > - We may need to rethink whether LDFLAGS or the contents of a different
> >   variable should be passed to the reload line;
> >   There are traps to avoid here in several directions; I haven't thought
> >   through this completely; probably necessary to just filter out a few
> >   flags we can allow through, like -64 or so.
> >   
> Will investigate.

Ultimatively, I'm afraid this will be "fixed" by waiting for user bug
reports and adding all the flags that are sane here, but investigating
will surely help.

> In the mine field area, there is also something I had not considered
> previously, that need some thinking :
> I don't know yet how the patch and the test cases behaves in case of
> cross compiling (well, cross linking to be exact).

I don't see any problem here, why?  Just make sure you use
LT_AT_EXEC_CHECK everywhere you may happen to execute a compiled
program.

> > - I believe you cannot assume `strings' to be present (unsure about
> >   this), so it would be prudent to test this.
> > - `! test' is not portable, but `test !' is.
> 
> Short of reading the POSIX spec to find what is portable in theory, and
> the bug reports all other the Internet
> to find what is portable in practice, can you or anyone recommend :

Eric already gave pointers here.  The GCS has a list of commands one may
consider available upon installation
  info maintain "Install Command Categories"

which is a good general guide.  Probably, strings is quite portable in
practice.

I actually warned about strings because a comment in
tests/demo-hardcode.test mentions that AIX doesn't have strings(1).
I haven't traced back when that was added, but the AIX >= 4.3.3 systems
which I have access to all have it.

> > Corner cases:
> > - some objects have been compiled PIC-only, then the corresponding
> >   objects will be missing in the output.  I think this is a bug in the
> >   current patch.
> >   
> Don't know in detail what this refers to, will have to get back to you
> on that.

Say, the libtool script has both library types enabled.

  echo 'int a() { return 0; }' > a.c
  libtool --tag=disable-static --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c
  echo 'int b() { return 0; }' > b.c
  libtool --mode=compile $CC $CPPFLAGS $CFLAGS b.c
  libtool --mode=link $CC $CFLAGS $LDFLAGS -o reloc.lo a.lo b.lo

Then .libs/reloc.o will contain .libs/a.o and .libs/b.o, while reloc.o
will contain b.o only.  I think that's inconsistent, and it should
contain .libs/b.o as well in this case.  Note this is not symmetric: you
may not substitute a non-PIC object for a PIC one.

Note that even the above substitution that I suggest is not desirable
for some projects, notably ones that use assembler which differs in the
two cases; but they can control this, so let's worry about the general
case.

Note that I don't know whether adding $CFLAGS to the reloc link line is
useful or desirable.  At the moment, we do partial linking almost
exclusively by resorting to $LD, not to $CC.

> The good part about the duplication is that the tests are really, really
> dumb, and self contained, so this was actually on purpose.
> This decreases the chance of a bug in the test code itself, maybe due to
> more complex m4 macros expanding
> the wrong way without noticing it, that could mask a real bug in the
> production code.

The bad part is that if we find a bug, or enhance one test, we forget to
do so with the other tests; IOW, it's more maintenance work.

> > I don't like the testing with "strings" for another reason: that's not
> > what you would do with the output in real projects; instead, you would
> > link the output into some program, or library.  So that is what the
> > tests should do, verifying that the needed symbols are present.  
> 
> Using strings(1) allows to inspect more closely the binary itself.
> Since, after all, the result is a binary object, looking at the object
> itself seemed like a good idea to me.

Yes.  $NM wouldn't be so bad either, for example.  Except you'll be
surprised at how much output it produces on some systems.

Wrt. strings output, some systems store the command line used to compile
in the object, for example.

> In the same line of thought, I have considered using file(1) and
> magic(4) to make sure that the "binary"
> object is what it's expected to be.

MinGW/MSYS doesn't have file(1).

> > | AT_CHECK(
> > |    [($LIBTOOL --features | grep "enable static libraries" ) || exit 77],
> > |    [0],
> > |    [ignore],
> > |    [ignore])
> >
> > You could just have one test that does --tag=disable-shared; since the
> > user may want to do this, it's exactly what the test should try.
> >   
> I don't understand, but will look into that in more details.

libtool has some yet-undocumented options
  --tag=disable-shared
  --tag=disable-static

which, as of version >= 1.5.22, should work reasonably.
They must come early on the command line, though.

Cheers, and thank you for putting work into this!
Ralf




reply via email to

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