Re: cyggfortran-3.dll broken ?
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
Re: cyggfortran-3.dll broken ?
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 ?
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 ?
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.09375 + +++ b 2011-03-23 16:10:13.328125000 + @@ -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 ?
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.09375 + +++ b 2011-03-23 16:10:13.328125000 + @@ -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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
Re: cyggfortran-3.dll broken ?
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 ?
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 ?
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 ?
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
