cyggfortran-3.dll broken ?

cyggfortran-3.dll broken ?

[marco atzeri]

Dave,
the new cyggfortran-3.dll seems to provide less export than before.
This breaks octave.

Dependency walker check on octave highlight 3 functions in red
clogf, cexpf, csqrtf

Is the new fortran library broken, or should I release a new octave on
the flight ?

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Dave Korn]

On 23/03/2011 15:02, marco atzeri wrote:
> Dave,
> the new cyggfortran-3.dll seems to provide less export than before.
> This breaks octave.
> 
> Dependency walker check on octave highlight 3 functions in red
> clogf, cexpf, csqrtf
> 
> Is the new fortran library broken, or should I release a new octave on
> the flight ?

  Sounds like a build error, am looking into it.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Dave Korn]

On 23/03/2011 15:53, Dave Korn wrote:
> On 23/03/2011 15:02, marco atzeri wrote:
>> Dave,
>> the new cyggfortran-3.dll seems to provide less export than before.
>> This breaks octave.
>>
>> Dependency walker check on octave highlight 3 functions in red
>> clogf, cexpf, csqrtf
>>
>> Is the new fortran library broken, or should I release a new octave on
>> the flight ?
> 
>   Sounds like a build error, am looking into it.

  Somehow all these have gone missing:

> $ diff -pu a b
> --- a   2011-03-23 16:10:15.093750000 +0000
> +++ b   2011-03-23 16:10:13.328125000 +0000
> @@ -1,27 +1,5 @@
> -carg
> -cargf
> -ccos
> -ccosf
> -ccosh
> -ccoshf
> -cexp
> -cexpf
> -clog
>  clog10
>  clog10f
> -clogf
> -cpow
> -cpowf
> -csin
> -csinf
> -csinh
> -csinhf
> -csqrt
> -csqrtf
> -ctan
> -ctanf
> -ctanh
> -ctanhf
>  floorl
>  fmodl
>  log10l

  Have no idea how yet but yes, you'd better roll back your libgfortran DLL to
prev: for now.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[marco atzeri]

On Wed, Mar 23, 2011 at 5:11 PM, Dave Korn  wrote:
> On 23/03/2011 15:53, Dave Korn wrote:
>> On 23/03/2011 15:02, marco atzeri wrote:
>>> Dave,
>>> the new cyggfortran-3.dll seems to provide less export than before.
>>> This breaks octave.
>>>
>>> Dependency walker check on octave highlight 3 functions in red
>>> clogf, cexpf, csqrtf
>>>
>>> Is the new fortran library broken, or should I release a new octave on
>>> the flight ?
>>
>>   Sounds like a build error, am looking into it.
>
>  Somehow all these have gone missing:
>
>> $ diff -pu a b
>> --- a   2011-03-23 16:10:15.093750000 +0000
>> +++ b   2011-03-23 16:10:13.328125000 +0000
>> @@ -1,27 +1,5 @@
>> -carg
>> -cargf
>> -ccos
>> -ccosf
>> -ccosh
>> -ccoshf
>> -cexp
>> -cexpf
>> -clog
>>  clog10
>>  clog10f
>> -clogf
>> -cpow
>> -cpowf
>> -csin
>> -csinf
>> -csinh
>> -csinhf
>> -csqrt
>> -csqrtf
>> -ctan
>> -ctanf
>> -ctanh
>> -ctanhf
>>  floorl
>>  fmodl
>>  log10l
>
>  Have no idea how yet but yes, you'd better roll back your libgfortran DLL to
> prev: for now.
>
>    cheers,
>      DaveK
>

May be as they are now available from cygwin-1.7.8 ?

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Dave Korn]

On 23/03/2011 16:19, marco atzeri wrote:

> May be as they are now available from cygwin-1.7.8 ?

  Yes indeed (and this is why I didn't see any errors during the compiler
testsuite), I just had a quick look at the libgfortran autoconfigury, it
provides replacements for those functions when the standard libm doesn't
contain them.  Now that they are in the cygwin dll, libgfortran doesn't need
to provide them anymore but this has the unfortunate side-effect of breaking
old executables, since on Windows an imported function reference in an
executable has to specify not just the function name but also the particular
DLL from which the import comes.

  I imagine that on ELF platforms where the executable just has a list of
undefined functions and a list of shared libs to load and the dynamic linker
just satisfies an undefined symbol from whichever lib it first comes across a
definition of it, this probably works without anything needing changing.  But
we're stuck I'm afraid when exports move around like this.

  Sorry, looks like you'll need to respin after all.

    cheers,
      DaveK

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[marco atzeri]

On Wed, Mar 23, 2011 at 5:27 PM, Dave Korn  wrote:
> On 23/03/2011 16:19, marco atzeri wrote:
>
>> May be as they are now available from cygwin-1.7.8 ?
>
>  Yes indeed (and this is why I didn't see any errors during the compiler
> testsuite), I just had a quick look at the libgfortran autoconfigury, it
> provides replacements for those functions when the standard libm doesn't
> contain them.  Now that they are in the cygwin dll, libgfortran doesn't need
> to provide them anymore but this has the unfortunate side-effect of breaking
> old executables, since on Windows an imported function reference in an
> executable has to specify not just the function name but also the particular
> DLL from which the import comes.
>
>  I imagine that on ELF platforms where the executable just has a list of
> undefined functions and a list of shared libs to load and the dynamic linker
> just satisfies an undefined symbol from whichever lib it first comes across a
> definition of it, this probably works without anything needing changing.  But
> we're stuck I'm afraid when exports move around like this.
>
>  Sorry, looks like you'll need to respin after all.
>
>    cheers,
>      DaveK
>

So I caused myself the problem as I added all those functions to cygwin....

Stay tuned for the octave respin.

Ehm, may be also respin of
libarpack0, liblapack0, libnetcdf6, libqrupdate0

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Don Ward]

marco atzeri wrote:

> Sent: Wednesday, March 23, 2011 12:36 PM
> Subject: Re: cyggfortran-3.dll broken ?

[snip...]

> So I caused myself the problem as I added all those functions to 
> cygwin....

But they were just in time to save me having to abandon my primary 
application on Cygwin.  Thank you.  Your efforts are appreciated.

Best regards,

-- Don W.

[snip...]

> Regards
> Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[marco atzeri]

On Wed, Mar 23, 2011 at 5:36 PM, marco atzeri  wrote:
> On Wed, Mar 23, 2011 at 5:27 PM, Dave Korn  wrote:
>> On 23/03/2011 16:19, marco atzeri wrote:
>>
>>
>>  Sorry, looks like you'll need to respin after all.
>>
>>    cheers,
>>      DaveK
>>
>
> So I caused myself the problem as I added all those functions to cygwin....
>
> Stay tuned for the octave respin.
>
> Ehm, may be also respin of
> libarpack0, liblapack0, libnetcdf6, libqrupdate0

it seems I need to respin almost all of them plus octave and octave-forge,
it will take a while....

>
> Regards
> Marco
>

as interim workaround, can you put

libgfortran3         4.3.4-3 as current and
libgfortran3         4.3.4-4 as test ?

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Corinna Vinschen]

On Mar 23 16:27, Dave Korn wrote:
> On 23/03/2011 16:19, marco atzeri wrote:
> 
> > May be as they are now available from cygwin-1.7.8 ?
> 
>   Yes indeed (and this is why I didn't see any errors during the compiler
> testsuite), I just had a quick look at the libgfortran autoconfigury, it
> provides replacements for those functions when the standard libm doesn't
> contain them.  Now that they are in the cygwin dll, libgfortran doesn't need
> to provide them anymore but this has the unfortunate side-effect of breaking
> old executables, since on Windows an imported function reference in an
> executable has to specify not just the function name but also the particular
> DLL from which the import comes.
> 
>   I imagine that on ELF platforms where the executable just has a list of
> undefined functions and a list of shared libs to load and the dynamic linker
> just satisfies an undefined symbol from whichever lib it first comes across a
> definition of it, this probably works without anything needing changing.  But
> we're stuck I'm afraid when exports move around like this.
> 
>   Sorry, looks like you'll need to respin after all.

Is there a way to add symbol forwarding in GCC?  There's some method of
forwarding symbol references to other DLLs and it's used in Windows
itself to forward symbol references to other DLLs.  For instance, some
kernel32 APIs are just forwarded to equivalent ntdll APIs).  I'm not
familiar with how to implement it, I just read about it in
http://msdn.microsoft.com/en-us/magazine/cc301727.aspx


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Dave Korn]

On 23/03/2011 16:36, Corinna Vinschen wrote:

> Is there a way to add symbol forwarding in GCC?  There's some method of
> forwarding symbol references to other DLLs and it's used in Windows
> itself to forward symbol references to other DLLs.  

  Yes, was using that just the other day myself, to build a replacement ws2_32
dll consisting entirely of forwarders to the real dll with a handful of new
functions(*).

  So, we could in theory replace the old entries in libgfortran with
forwarding entries that point to the newly-available cygwin dll
implementations and that would allow old programs to link.

  I think however I might wait 48 hours and see how many people complain and
how big a problem this is.  If Marco only has a handful of Octave users, it
might be easiest to just do the transition once and for all and get it over with.

    cheers,
      DaveK
-- 
(*) - If anyone wants to run the Android emulator on win2k, drop me a line
off-list.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Charles Wilson]

On 3/23/2011 12:19 PM, marco atzeri wrote:
> May be as they are now available from cygwin-1.7.8 ?

Oh, good point.  Is there a way to add export forwarding to the new
cygfortran-3.dll (but not the implib)?

That way, the old apps will still get (think they are getting) the
functions from the fortran dll, but newly compiled apps will use the
ones from cygwin1.dll directly.

I think it would just take a few statements in a .def file like

  carg   = CYGWIN1.carg
  cargf  = CYGWIN1.cargf
  ccos   = CYGWIN1.ccos

but I'm not sure...
http://msdn.microsoft.com/en-us/magazine/cc301808.aspx

And, of course, the process of building gcc runtime libraries is a
bit...opaque...so "adding blah to a .def file" may be harder than it
sounds.  And if you DO it this way, I'm pretty sure ld will go ahead and
create import entries in the .dll.a for them.

Or is it simply time to bump the DLL number for cygwin's gfortran runtime?

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Dave Korn]

On 23/03/2011 16:35, Charles Wilson wrote:

> I think it would just take a few statements in a .def file like
> 
>   carg   = CYGWIN1.carg
>   cargf  = CYGWIN1.cargf
>   ccos   = CYGWIN1.ccos
> 
> but I'm not sure...

  Yes, that's basically it (or equivalent in a .directve section), but,
indeed, as you point out:

> And, of course, the process of building gcc runtime libraries is a
> bit...opaque...so "adding blah to a .def file" may be harder than it
> sounds.

  Nah, it's only libtool and autoconf, nothing to be scared of!

>  And if you DO it this way, I'm pretty sure ld will go ahead and
> create import entries in the .dll.a for them.

  Yes, that's what we'd want to happen isn't it?  The import stub imports the
symbol from libgfortran, the runtime loader finds it in libgfortran and
performs the forwarding, everything Just Works.  No?

> Or is it simply time to bump the DLL number for cygwin's gfortran runtime?

  Urgh.  Don't want to diverge our DLL numbers from upstream if at all possible.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Charles Wilson]

On 3/23/2011 12:57 PM, Dave Korn wrote:
> On 23/03/2011 16:35, Charles Wilson wrote:

>>  And if you DO it this way, I'm pretty sure ld will go ahead and
>> create import entries in the .dll.a for them.
> 
>   Yes, that's what we'd want to happen isn't it?  The import stub imports the
> symbol from libgfortran, the runtime loader finds it in libgfortran and
> performs the forwarding, everything Just Works.  No?

Err...no, I don't think so.  Symbol forwarding is actually implemented
as part of the PE-I386 spec, so it resides in the forwardING dll itself,
not the import library, and is handled at runtime by the windows loader:

http://msdn.microsoft.com/en-us/magazine/cc301808.aspx
> Export Forwarding
> A particularly slick feature of exports is the
> ability to "forward" an export to another DLL. For example, in
> Windows NT®, Windows® 2000, and Windows XP, the KERNEL32 HeapAlloc
> function is forwarded to the RtlAllocHeap function exported by NTDLL.
> Forwarding is performed at link time

of the forwardING dll, not the client app.

> by a special syntax in the
> EXPORTS section of the .DEF file. Using HeapAlloc as an example,
> KERNEL32's DEF file would contain:
> 
> EXPORTS
>    HeapAlloc = NTDLL.RtlAllocHeap
> 
> How can you tell if a function is forwarded rather than exported
> normally? It's somewhat tricky. Normally, the EAT contains the RVA of
> the exported symbol. However, if the function's RVA is inside the
> exports section (as given by the VirtualAddress and Size fields in
> the DataDirectory), the symbol is forwarded. When a symbol is
> forwarded, its RVA obviously can't be a code or data address in the
> current module. Instead, the RVA points to an ASCII string of the DLL
> and symbol name to which it is forwarded. In the prior example, it
> would be NTDLL.RtlAllocHeap.

So, if you simply drop in a new cygfortran-3.dll that has a forward for
(e.g.) cargf, then marco's CURRENT (and currently broken) octave will
suddenly start working.

However, by NOT having a thunk present in the import library, then when
linking a new client the symbol will be resolved by libcygwin.a and will
show up in the new client's import list as coming directly from cygwin1.dll.

I think that would be the ideal situation, but it's obviously more work
than any other solution.

>> Or is it simply time to bump the DLL number for cygwin's gfortran runtime?
> 
>   Urgh.  Don't want to diverge our DLL numbers from upstream if at all possible.

Well, you are removing a number of functions that cygfortran used to
provide.  That's a backwards incompatible API change.  So, under
ordinary rules that would require a version number bump.  So, if you
made NO accommodation, then you'd really need to bump the vernum.

Unless you feel that given only one, or very few, major clients, that
it'd be "ok" to break the usual versioning rules for cygwin's fortran
runtime library, in the interests of maintaining your sanity.

OTOH, if you add forwarders or .drectives for the "removed" symbols --
whether corresponding thunks appear in the import library or not -- then
you wouldn't need to bump the vernum.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Dave Korn]

On 23/03/2011 17:31, Charles Wilson wrote:

> Err...no, I don't think so.  Symbol forwarding is actually implemented
> as part of the PE-I386 spec, so it resides in the forwardING dll itself,
> not the import library, and is handled at runtime by the windows loader:

  Yes yes yes, you're jumping too far ahead; what I was pointing out is that
you still have to have an import stub in order to pull in the import from the
forwarding DLL.

> However, by NOT having a thunk present in the import library, then when
> linking a new client the symbol will be resolved by libcygwin.a and will
> show up in the new client's import list as coming directly from cygwin1.dll.

  Well that seems like it would be cleaner in theory, but it would still
constitute a change to the ABI exported by libgfortran, which is what we were
trying to avoid; if we're keeping the ABI constant, then future fortran apps
linked against libgfortran should also continue to get their math functions
from there rather than cygwin1.

  We'd want to keep the forwarders in place forever, and here's the good thing
about how it works: regardless which dll.a the import stub comes from and how
many DLLs it does or doesn't forward through before it reaches the actual
implementation, that's all indirected away by the loader and at run-time it's
still just a single indirect jump in both cases.

  Hmm, I should probably do this.  And send it upstream too.  But I'll
prioritise it lower than bringing newer compiler versions onstream unless we
start to get a lot of problem reports.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

FW: cyggfortran-3.dll broken ?

[Karl M]

> Date: Wed, 23 Mar 2011 17:49:42 +0000
> From: dave.korn
> Subject: Re: cyggfortran-3.dll broken ?
> 
> On 23/03/2011 17:31, Charles Wilson wrote:
> 
> > Err...no, I don't think so. Symbol forwarding is actually implemented
> > as part of the PE-I386 spec, so it resides in the forwardING dll itself,
> > not the import library, and is handled at runtime by the windows loader:
> 
> Yes yes yes, you're jumping too far ahead; what I was pointing out is that
> you still have to have an import stub in order to pull in the import from the
> forwarding DLL.
> 
> > However, by NOT having a thunk present in the import library, then when
> > linking a new client the symbol will be resolved by libcygwin.a and will
> > show up in the new client's import list as coming directly from cygwin1.dll.
> 
> Well that seems like it would be cleaner in theory, but it would still
> constitute a change to the ABI exported by libgfortran, which is what we were
> trying to avoid; if we're keeping the ABI constant, then future fortran apps
> linked against libgfortran should also continue to get their math functions
> from there rather than cygwin1.
> 
> We'd want to keep the forwarders in place forever, and here's the good thing
> about how it works: regardless which dll.a the import stub comes from and how
> many DLLs it does or doesn't forward through before it reaches the actual
> implementation, that's all indirected away by the loader and at run-time it's
> still just a single indirect jump in both cases.
> 
> Hmm, I should probably do this. And send it upstream too. But I'll
> prioritise it lower than bringing newer compiler versions onstream unless we
> start to get a lot of problem reports.
> 
What if you just put the functions back in until the next gfortran dll version bump?

...Karl 		 	   		  

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Fw: Re: FW: cyggfortran-3.dll broken ?

[Dave Korn]

On 23/03/2011 18:15, Karl M wrote:

> > What if you just put the functions back in until the next gfortran dll
> > version bump?

  That's a thought too.  I could just hack around the autoconf tests and make
it keep using its own implementation.  Thanks for the suggestion.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Charles Wilson]

On 3/23/2011 1:49 PM, Dave Korn wrote:
> On 23/03/2011 17:31, Charles Wilson wrote:
> 
>> Err...no, I don't think so.  Symbol forwarding is actually implemented
>> as part of the PE-I386 spec, so it resides in the forwardING dll itself,
>> not the import library, and is handled at runtime by the windows loader:
> 
>   Yes yes yes, you're jumping too far ahead; what I was pointing out is that
> you still have to have an import stub in order to pull in the import from the
> forwarding DLL.

True -- you must have stubs in libgfortran.a *if* you want newly
compiled clients to use (whatever is in cyggfortran-3.dll, whether an
actual implementation or a pe-i386 windows-loader-supported forwarding
operation) instead of just resolving the symbol directly at link time
via libcygwin.a/cygwin1.dll.

>> However, by NOT having a thunk present in the import library, then when
>> linking a new client the symbol will be resolved by libcygwin.a and will
>> show up in the new client's import list as coming directly from cygwin1.dll.
> 
>   Well that seems like it would be cleaner in theory, but it would still
> constitute a change to the ABI exported by libgfortran

Not really.  The ABI applies to the DLL, which would still have export
entries for all the symbols. It's just that some of them would be
forwarding entries.

If you removed the stubs for those functions now "implemented" as
forwards, from libgfortran.dll.a (or removed the static impls from
libgfortran.a) it is technically an ABI change, but one that doesn't
REALLY matter, because you know those symbols will be provided by
libcygwin.a for newly compiled clients.

The limitation would come in that the new gfortran library system, and
any (new) apps compiled with it, would require to be built and run only
on cygwin-1.7.8 or newer.

But that's nothing "new" -- this happens all the time (and it's true
already, thanks to the fenv issue).  Dunno if the gcc devs want to
ensconce that idea in their code, tho (see below).

> which is what we were
> trying to avoid; if we're keeping the ABI constant, then future fortran apps
> linked against libgfortran should also continue to get their math functions
> from there rather than cygwin1.

Well, maybe. Ugly...

>   We'd want to keep the forwarders in place forever

Yeah, I know.  That's what I'd like to avoid: permanent workarounds
originally required because of a cygwin deficiency, long since rectified.

> and here's the good thing
> about how it works: regardless which dll.a the import stub comes from and how
> many DLLs it does or doesn't forward through before it reaches the actual
> implementation, that's all indirected away by the loader and at run-time it's
> still just a single indirect jump in both cases.

True, the additional runtime cost is zero.

>   Hmm, I should probably do this.  And send it upstream too.

Well, yeah (but does upstream want to explicitly require cygwin-1.7.8 or
better? or would you conditionalize it on a configure test: add
forwarders if cgywin1.dll new enough and has the funcs, otherwise add
the .o's and local impl to libgfortran.)

> But I'll
> prioritise it lower than bringing newer compiler versions onstream unless we
> start to get a lot of problem reports.

Since octave & company are the only known clients, and marco's already
started a respin, sure...

--
Chuck


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Dave Korn]

On 23/03/2011 19:17, Charles Wilson wrote:
> On 3/23/2011 1:49 PM, Dave Korn wrote:

>>   Hmm, I should probably do this.  And send it upstream too.
> 
> Well, yeah (but does upstream want to explicitly require cygwin-1.7.8 or
> better? or would you conditionalize it on a configure test: 

  The latter, certainly.

  I had a quick try in my 4.3.4-4 build dir; it's a simple matter of adding an
extra.def file to the linker flags along with a counterbalancing
'--export-all-symbols' (and since we have a .map file as well this doesn't
over-export, so I don't need to make a complete .def file, handy!) and I could
conditionalize it on any one of the new HAVE_xxx definitions that are what's
causing libgfortan to exclude its own implementations in the new build, so it
doesn't seem like it should be too hard.

  I need to concentrate on fixing LTO for binutils 2.21.1 before I do anything
else.  Apologies to Marco but unless the problem gets worse I'm going back to
that and testing the gcc-4.6.0 RC2 for the next few days.  I'll try and find
some background time in which to respin 4.3.4 with forwarders added to the DLL.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[marco atzeri]

On Wed, Mar 23, 2011 at 8:40 PM, Dave Korn  wrote:
> On 23/03/2011 19:17, Charles Wilson wrote:
>> On 3/23/2011 1:49 PM, Dave Korn wrote:
>
>>>   Hmm, I should probably do this.  And send it upstream too.
>>
>> Well, yeah (but does upstream want to explicitly require cygwin-1.7.8 or
>> better? or would you conditionalize it on a configure test:
>
>  The latter, certainly.
>
>  I had a quick try in my 4.3.4-4 build dir; it's a simple matter of adding an
> extra.def file to the linker flags along with a counterbalancing
> '--export-all-symbols' (and since we have a .map file as well this doesn't
> over-export, so I don't need to make a complete .def file, handy!) and I could
> conditionalize it on any one of the new HAVE_xxx definitions that are what's
> causing libgfortan to exclude its own implementations in the new build, so it
> doesn't seem like it should be too hard.
>
>  I need to concentrate on fixing LTO for binutils 2.21.1 before I do anything
> else.  Apologies to Marco but unless the problem gets worse I'm going back to
> that and testing the gcc-4.6.0 RC2 for the next few days.  I'll try and find
> some background time in which to respin 4.3.4 with forwarders added to the DLL.

the new pc is faster than old one. 2-3 days I should repack all

>
>    cheers,
>      DaveK
>

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Daniel Jensen]

Since Dave Korn was wondering how many people this would be bothering, 
I'm just chiming in to say I was bitten by this too (since I both run 
cygwin setup less often than others and use octave less often than 
others, and since I'm not subscribed to the list, I'm late to the 
party). It was kind of baffling to have no output, error message, core 
dump, etc- just an immediate return regardless of what command line 
options I specified- and to have cygcheck say all was well with the 
library situation. Thankfully the thread "Octave 3.4.0 crashes silently 
on the latest cygwin 1.7.8 " over on the Octave mailing list came up 
high in search results and led to this thread.

For me, just rolling back libgfortran is fine, and though I think it's 
kind of rough to have such API breakage in a upgrade which doesn't 
change the version number at all (just the build number), I'd certainly 
prefer that limited development resources be spent on getting gcc 4.6 
and associated binutils etc ready for prime time.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cyggfortran-3.dll broken ?

[Dave Korn]

On 29/03/2011 02:24, Daniel Jensen wrote:
> Since Dave Korn was wondering how many people this would be bothering,
> I'm just chiming in to say I was bitten by this too (since I both run
> cygwin setup less often than others and use octave less often than
> others, and since I'm not subscribed to the list, I'm late to the
> party). It was kind of baffling to have no output, error message, core
> dump, etc- just an immediate return 

  I'm sure there was an error code set in the $? shell variable, but we do
have a reporting issue there that bash doesn't always issue a message when a
process fails with an error status.

> regardless of what command line
> options I specified- and to have cygcheck say all was well with the
> library situation. 

  Yeh, this is a limitation of cygcheck; it only checks if the named DLLs are
present, not if they have all the necessary imports that the executable
actually requires.  It /could/ be added to cygcheck but would need a good deal
of extra code to be written by someone.



    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple