On 6/17/2010 3:58 PM, Dave Korn wrote:
> On 17/06/2010 16:23, Charles Wilson wrote:
>
>> As expected, this didn't work. But...the imports and exports are NOT
>> what I expected, so I'm a little confused:
>
>> Err, what? (a) why is this DLL exporting modexc stuff, when it is marked
>> dllimport in
On 17/06/2010 16:23, Charles Wilson wrote:
> As expected, this didn't work. But...the imports and exports are NOT
> what I expected, so I'm a little confused:
> Err, what? (a) why is this DLL exporting modexc stuff, when it is marked
> dllimport in this context? (b) why is this DLL exporting std:
On Thu, 17 Jun 2010 10:05 -0400, "Charles Wilson" wrote:
> On 6/17/2010 9:50 AM, Dave Korn wrote:
> > To summarize the summary of the summary: C++ is complicated.
>
> No kidding. What if the datatypes used in the interface between the
> module and main -- including ALL exception classes -- were
On 6/17/2010 9:50 AM, Dave Korn wrote:
> To summarize the summary of the summary: C++ is complicated.
No kidding. What if the datatypes used in the interface between the
module and main -- including ALL exception classes -- were defined in a
second DLL, on which both module and main depend? Th
On 17/06/2010 13:15, Dave Korn wrote:
> On 17/06/2010 03:41, Charles Wilson wrote:
>
>> Any ideas?
>
> Yes, I have one:
>
>> catch (modexc e) {
>> std::cerr << "caught: " << e.what () << '\n';
>> if (dlclose (handle))
>> {
>> std::cerr << "dlclose failed: " << dlerror (
On 17/06/2010 03:41, Charles Wilson wrote:
> Any ideas?
Yes, I have one:
> catch (modexc e) {
> std::cerr << "caught: " << e.what () << '\n';
> if (dlclose (handle))
> {
> std::cerr << "dlclose failed: " << dlerror () << '\n';
> return 1;
> }
> return
This problem came up on the libtool list, while trying to track down a
regression test failure on with cygwin-libtool-2.2.10. It's actually
not a "regression" per se, because the same test failed also on
cygwin-libtool-2.2.7a. However, it really shouldn't fail, AFAICT.
Anyway, the STC is attache
7 matches
Mail list logo
