Hello Gary,
Apologies for the huge delay.
* Gary V. Vaughan wrote on Tue, May 08, 2007 at 04:42:09PM CEST:
>
> Thanks for the review :-) Patch now committed to CVS.
Thank you.
>> handle is never closed here. This is important: some failures are only
>> caught at module closing time.
>
> in main I've written:
>
> if (lt_dlexit () != 0)
> complain ("error during exit");
>
> Is there something this won't catch?
Ahh, that should be sufficient for this test. Thanks for the pointer.
>>> +$CC $CPPFLAGS $CFLAGS -c main.c
>>> +for file in modresident modlocal modglobal moddepend; do
>>> + $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c $file.c
>>> + AT_CHECK([$LIBTOOL --mode=link $CC -module $CFLAGS $LDFLAGS -o
>>> $file.la \
>>> + $file.lo -rpath /foo -avoid-version], [], [ignore],
>>
>> What about -no-undefined, for w32?
>
> That would defeat building moddepend with unresolved symbols at link time,
> so that we can test that it correctly calls the matching symbols from
> modglobal after load time symbol resolution :-( Known issue, but I don't
> know how to fix it. I guess we'll need to skip this test on Windows and
> AIX due to linker brain damage?
Erm. First, we can use -no-undefined for all but moddepend, no?
Second, we could avoid moddepend on w32. Hmm. This seems like
an undesirable situation. If we named the modules with a `lib'
prefix, then there would be one less issue. If we linked `moddepend'
against the other modules it depends upon at mode=link time, that
would work on w32, except now libtool still outputs the warning
| *** Warning: Linking the executable m against the loadable module
| *** liba.so is not portable!
which is in place because of Darwin. Hmm. It's just a warning --
libtool will try to link against the static copy of the module.
I guess a proper test would use a separate, real shared library
which moddepend would then depend upon. WDYT?
Cheers,
Ralf
