bug-libtool
[Top][All Lists]
Advanced

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

Re: [libtool 2.2.11a] testsuite: 48 69 92 failed [cygwin]


From: Charles Wilson
Subject: Re: [libtool 2.2.11a] testsuite: 48 69 92 failed [cygwin]
Date: Sat, 19 Jun 2010 15:07:24 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

On 6/16/2010 10:32 PM, Charles Wilson wrote:
> Yep, that fails too (not surprising, given Bob's reply).  However, while
> this may or may not be specific to cygwin-gcc, I think I'll run it by
> the cygwin list and Dave Korn first, before opening a gcc bugzilla.
> Dave'll probably tell me to go ahead and do it, but...

Well, it turns out there appear to be three separate problems here. Only
the first of which *really* matters as far as we are concerned.

See this thread:
http://cygwin.com/ml/cygwin/2010-06/msg00392.html

1) Violations of the "rule": Don't unload a shared library while you
still have a live C++ object from it, unless that object is a POD. The
issue here is inside the catch() block,

> the modexc object e has not yet been destructed, the catch is still
> 'live', [and when you attempt to exit the catch block],
> __cxa_end_catch gets fatally confused.  The live exception still
> contains pointers into where the dll used to be loaded: it has
> typeinfo there, and a pointer to the module's inlined instance of
> the ~modexc() dtor.

I believe this is probably a cross-platform (or, affecting multiple
compilers) issue.  Or at least, it could be.  The C++ standard doesn't
really say anything about how shared libraries behave; that's a platform
ABI and/or C++ compiler ABI thing...


2) ODR issues with the definition of the exception class.  While on
linux, the code may technically be in violation, in practice it is ok
and works. But on win32 with DLLs...it is NOT ok. The problem is that
both main and module have their own definitions of modexc; both main and
lib have their own definitions of libexc.  To avoid this, module's
version of modexc should be dllexport, while main's version should be
dllimport. Ditto libexc.

However, to do this correctly, main needs to "statically" link to the
vtable for modexc (that is, resolve at linktime).  If this were done
directly to module.dll, then you'd have a direct dependence, and
"dlopen" would be rather nonsensical (e.g. testing "module" would be
identical to testing "lib")

So...to do this right, you have to also put the classes that are exposed
in the interface between the client (main) and the module -- including
exception types like modexc -- into a separate DLL, which both main and
module can link "statically" against.

That leads to...

3) A bug in the linker where --export-all-symbols re-exports symbols
imported from another library.  However, this only appears in the test
case from gcc bugzill 43581 (AFTER the mods similar to the above are
employed), where -e-a-s is used directly when building the DLLs.
However, with libtool, and as the test is written currently, -e-a-s
isn't used when linking the DLLs, so this linker bug is not exposed.


The first patch attached fixes (1), and enables this test to pass on cygwin.

The second one extends/includes the first, but also fixes (2). I moved
the definition of modexc into libcommon, and linked both module and main
against it. I left libexc where it was, in liba.


I didn't bother to "fix" (3), since it isn't really exposed here. It
would be, if we used -regex-symbols or something.



As Dave put it, C++ is complicated.  Which solution should I propose on
libtool-patches? (I'll work up full changelog entries, test on linux &
mingw, etc, once it's decided which path to pursue).

--
Chuck


Attachment: cygwin-c++-exceptions-test.patch1
Description: Text document

Attachment: cygwin-c++-exceptions-test.patch2
Description: Text document


reply via email to

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