Re: Curious Windows GHCi linker behaviour .o vs. .dll
Hello! On 2014-10-12 at 04:30:13 +0200, cg wrote: [...] Are you using 64-bit ghc? If so, it looks the issue is 64-bit only. Indeed, I have only set up 64bit CygWin MSYS2 environments so far. Actually both _tzset and tzset exist in include/time.h, only tzset is old style name. They will be linked as the same function __imp__tzset. What do you mean by old style? And more importantly, what foreign-import line shall be used that works both on Windows and non-Windows platforms, compiled as well as interpreted in GHCi? I meant OLDNAME in MS's jargon, because they deprecate tzset [1], then call it 'old'. But it it still usable. [1] http://msdn.microsoft.com/en-us/library/ms235451.aspx Ok, thanks for clairification, so I see there are actually two entangled issues here: 1) When coding directly against the MSVCRT, one is supposed to use the underscore-prefixed POSIX symbols, like e.g `_tzset()`. However, when targetting CygWin, using the proper `tzset()` POSIX name is the recommended course of action. To this end, I've submitted https://github.com/haskell/time/pull/4 (I hope that works for 32bit MSYS2 environments as well) Personally, I think this was a very questionable decision on Microsoft's part, as this way you effectively destroy any chance to simply compile existing POSIX-compatible source code for no good reason... 2) The other issue seems to be that while linking a package using `tzset()` into a `.exe`, `tzset()` gets resolved just fine, however as soon as GHCi's linker is used to resolve `tzset()` contained in that package, it fails. At this point, I still consider this a bug. It was suggested by Brandon, that GHCi's linker fails to resolve weak symbols. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Curious Windows GHCi linker behaviour .o vs. .dll
On Sun, Oct 12, 2014 at 6:11 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Personally, I think this was a very questionable decision on Microsoft's part, as this way you effectively destroy any chance to simply compile existing POSIX-compatible source code for no good reason... POSIX doesn't specify asm or linker level symbols, only C API. Most Unix-like platforms have an underscore on the front of symbol names at link level, so that the API doesn't have to avoid random platform-specific register names or the assembler need to have magic prefixes on either symbols or register names. So in fact, by adding the prefix underscore they are *more* compatible with Unix linkage, and presumably the FFI for Windows needs to start adding it the way the one for Unix does. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Broken build: 32-bit FreeBSD, SmartOS, Solaris
Sorry about this folks, I'm going to guess at the fix and validate it. Cheers, Simon On 10/10/2014 10:51, Karel Gardas wrote: On 10/10/14 09:19 AM, Páli Gábor János wrote: Hello there, Looks one of the recent commits broke the x86 builds on multiple platforms [1][2][3]. The common error message basically is as follows: rts/Linker.c: In function 'mkOc': rts/Linker.c:2372:6: error: 'ObjectCode' has no member named 'symbol_extras' It looks like this patch is the culprit: 5300099ed rts/Linker.c (Simon Marlow 2014-10-01 13:15:05 +0100 2372)oc-symbol_extras = NULL; Note that the x86_64 counterparts of the affected builders completed their builds fine -- except for Solaris, but that has been broken already for a long time (relatively). Yeah, I'll need to fix that. So far I invested my energy in fixing Solaris/i386 testcase issues... Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building ghc on Windows with msys2
However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on Windows than 4.8.3. 'Mingw-builds' project (which is now a part of mingw-w64 project and is considered to be an official mingw-w64 gcc distribution and is maintained by a man close to Msys2 project) has very nice and complete build of 4.8.3 (64-bit build, for example, is here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting% 20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/). I am looking into migrating ghc to the newer gcc package linked above. There is also the associated question of what to do with ghc-tarballs. Here's an idea: how about downloading the mingw package directly from sourceforge at configure time with curl/wget? That should work pretty well. I see two potential issues: 1. URL stability. The sourceforge repo is not in our control and files in it could go away any time. The repo seems stable though, with some files from 2011. If we're concerned about this, copying the file to a domain under our control should not be a problem. I did not get any responses about who to contact about that though... 2. Download failing due to internet connectivity issues or missing proxy configuration. This could easily be addressed by printing a message with a URL and a filesystem location to put the file in the case that the download fails. If there are no objections, I'll proceed with whipping up a patch. -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Problems adding a custom section to a Windows binary
This is slightly offtopic, but maybe some of the Windows folks know an answer to this question. I've been working on #9686 https://ghc.haskell.org/trac/ghc/ticket/9686, but have been blocked by Windows rejecting all my attempts to add a custom section to a binary withthe error bash: ./c.exe: cannot execute binary file: Exec format error. I'm not sure if this is a gcc/binutils bug or not (the exact same commands with the same tools work fine on Linux binaries). I have filed http://sourceforge.net/p/mingw/bugs/2239 and https://sourceware.org/bugzilla/show_bug.cgi?id=17466 to see what the developers say, but have not gotten a response yet. Perhaps someone here knows what's going on? -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Problems adding a custom section to a Windows binary
On Sun, Oct 12, 2014 at 6:28 PM, Gintautas Miliauskas gintautas.miliaus...@gmail.com wrote: I'm not sure if this is a gcc/binutils bug or not (the exact same commands with the same tools work fine on Linux binaries). There are huge differences between Linux ELF and Windows PE32/PE64; it would not be surprising if libbfd had bugs in the latter but not the former. Beyond that, I don't know. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Problems adding a custom section to a Windows binary
My suggestion is to have GHC spit some assembler that it is already generating, and see if custom sections are used at any point. Edward Excerpts from Gintautas Miliauskas's message of 2014-10-12 15:28:40 -0700: This is slightly offtopic, but maybe some of the Windows folks know an answer to this question. I've been working on #9686 https://ghc.haskell.org/trac/ghc/ticket/9686, but have been blocked by Windows rejecting all my attempts to add a custom section to a binary withthe error bash: ./c.exe: cannot execute binary file: Exec format error. I'm not sure if this is a gcc/binutils bug or not (the exact same commands with the same tools work fine on Linux binaries). I have filed http://sourceforge.net/p/mingw/bugs/2239 and https://sourceware.org/bugzilla/show_bug.cgi?id=17466 to see what the developers say, but have not gotten a response yet. Perhaps someone here knows what's going on? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Building ghc on Windows with msys2
Hi Gintautas, This seems like a good idea to me. I was also wondering would it be a good idea to have configure also handle cabal/happy/alex in a similar way? It would be another step you don't manually have to do and would make it easier to insure that the right versions are installed. Regards, Tamar -- From: Gintautas Miliauskas gintau...@miliauskas.lt Sent: 13/10/2014 00:06 To: kyra ky...@mail.ru Cc: ghc-devs@haskell.org Subject: Re: Building ghc on Windows with msys2 However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on Windows than 4.8.3. 'Mingw-builds' project (which is now a part of mingw-w64 project and is considered to be an official mingw-w64 gcc distribution and is maintained by a man close to Msys2 project) has very nice and complete build of 4.8.3 (64-bit build, for example, is here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting% 20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/). I am looking into migrating ghc to the newer gcc package linked above. There is also the associated question of what to do with ghc-tarballs. Here's an idea: how about downloading the mingw package directly from sourceforge at configure time with curl/wget? That should work pretty well. I see two potential issues: 1. URL stability. The sourceforge repo is not in our control and files in it could go away any time. The repo seems stable though, with some files from 2011. If we're concerned about this, copying the file to a domain under our control should not be a problem. I did not get any responses about who to contact about that though... 2. Download failing due to internet connectivity issues or missing proxy configuration. This could easily be addressed by printing a message with a URL and a filesystem location to put the file in the case that the download fails. If there are no objections, I'll proceed with whipping up a patch. -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
