Re: export.at failure on MinGW

[Charles Wilson]

Ralf Wildenhues wrote:
> I suggest this patch to fix the export test on MinGW.  It did not fail
> on Cygwin due to auto-import, but on MinGW it did for the data objects.

That is odd, because mingw supports auto-import too.  (However, it might 
be "off" by default, since libraries created that way wouldn't be usable 
by msvc, which is one of the goals of mingw, at least for 
non-name-mangled languages.)  So, yeah, being a little more careful 
about declspec() niceties for mingw is probably a good thing.

> WDYT?  I guess stresstest.at needs a similar fix, but there the same
> code is currently used to link against a shared and a static version of
> the library, so that would need to be fixed as well.

Hmm.

> The only thing that's then still worrying me is that on Cygwin, the
> mdemo and mdemo_static programs sometimes throw segmentation faults
> on my system.  Not all the time though.

Well, it's failing all the time for me, but I'm not sure it's a 
segfault. What does "Hangup" mean, when reported by the shell after 
executing the app:

$ tests/mdemo/mdemo_static tests/mdemo/foo1.la tests/mdemo/libfoo2.la
Welcome to GNU libtool mdemo!
module name: foo1
module filename: foo1.a
module reference count: 1
** This is foolib 1 **
hello returned: 57616
hello is ok!
cos (0.0) = 1
sub() called
foo1 is ok!
module name: libfoo2
module filename: libfoo2.a
module reference count: 1
** This is foolib 2 **
hello returned: 57616
hello is ok!
sin (0.0) = 0
sub() called
foo2 is ok!
myfunc returned: 57616
myfunc is ok!
Hangup

$ echo $?
129

> And then on both Cygwin and MinGW test 16 (Link order of deplibs) still
> fails.  I guess I need to weaken it even further...

I see this, too.  I'll post a more thorough test report on the full test 
suite on cygwin, tomorrow evening.

--
Chuck