[Top][All Lists]

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

Re: mdemo2-make.test on MinGW failure in libtool 2-0 and head.

From: Ralf Wildenhues
Subject: Re: mdemo2-make.test on MinGW failure in libtool 2-0 and head.
Date: Thu, 4 Aug 2005 07:06:32 +0200
User-agent: Mutt/1.5.9i

Hi Peter,

* Peter Ekberg wrote on Fri, Jul 29, 2005 at 11:41:22AM CEST:
> I have looked at the reason why the mdemo2-make.test fails
> on MinGW.

Very nice!

> The reason is that the mlib_func symbol is not properly
> exported from libmlib (i.e. not present in the import lib).
> I see two solutions to make the test pass.
> 1. Add ' -export-symbols-regex "mlib_func"' to libmlib_la_LDFLAGS
> in tests/mdemo/
> 2. Add an dllexport declaration in tests/mdemo/mlib.c #ifdefed for
> MinGW. Or reuse the one from libltdl:
> LT_SCOPE int mlib_func(int, char **);
> I don't know if the mlib_func symbol is supposed to be exported
> from mlib without an explicit request to do so as in 1 above.
*snip nice explanations*

> Which of 1 and 2 seems like the best solution?

Hmm, I'm not sure I like either of these.

On the one hand: Some tests can actually serve as demonstrations on how
users could/should do things.  From that standpoint, LT_SCOPE should not
be used, it's not published interface.  (It's also not a good interface,
as Howard Chu demostrated some time ago.)  Adding a dllexport
declaration by hand seems even less nice.

OTOH, export-symbols-regex is nice, published interface, but it does not
work here: using ' -export-symbols-regex "mlib_func"' basically means
that _only_ mlib_func is exported.  This breaks mdemo2-make on systems
with GNU ld, where lt_dlpreload_default (and other symbols) will suddenly
be inaccessible to mdemo2/main.  

I believe libtool is being inconsistent on mingw here, because the last
sentence of this doc snippet:
| `-export-symbols-regex REGEX'
|      Same as `-export-symbols', except that only symbols matching the
|      regular expression REGEX are exported.  By default all symbols are
|      exported.

is not really true.

If we cannot guarantee this without source code changes, we need to
create an interface similar to LT_SCOPE (but not broken and generally
usable) to fix this.  Maybe our interface for symbol export can be
expanded?  In addition to something like: -also-export-symbols-regex
(no, I have not checked whether that can be implemented portably)
the use of several -export-symbols or -export-symbols-regex options per
library would be useful, for example.

Best would probably be if we looked at real-world users of this in order
to find a good solution.

> I have verified that both approaches solves the mdemo2 tests on
> branch-2-0.

And I can verify that this kills the last remaining FAIL for HEAD on my
linux/x86 -> i586-mingw32msvc (Debian gcc cross compiler package) cross
compile, which is cool!


reply via email to

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