- cabal-devel - Haskell.org

Re: Linker change in GHC 7.8 leads to widespread issues
by Yitzchak Gale 10 Dec '14

10 Dec '14

I wrote: > Aha! Thanks [to Bryan] for this explanation of what I have been > suffering from... > I can't wait for the point releases. I'll go with HEAD on one > of the branches for now. Unfortunately, this patch did *not* fix what I have been suffering from. I'm still getting segfaults. I'll describe what I'm doing. Please let me know if either of the two problems below are actual problems, or if I'm just missing something. I'll submit them as issues if they are problems. Sample code: http://github.com/ygale/test-text-icu The following procedure worked fine for 32 bit Windows versions of GHC previous to 7.8.* and with all recent versions of cabal-install. Using Haskell Platform 2014.2.0.0 (GHC 7.8.3) 64 bit on Windows 7. Using rev. caf257cd96e766b293943bbac07d766ec2f552dd of cabal, the latest rev. at the moment, on the 1.20 branch. I locally changed the version numbers in the cabal files of both Cabal and cabal-install so I could verify that I really am using cabal.exe from that revision. I verified in the source code that the -fPIC fix is included. Clone the above sample code, and unzip ICU4C 54.1 (currently the latest) for 64 bit Windows in a nearby folder. ***Problem #1 (minor): Relative linker paths don't work anymore cabal sandbox init cabal install --extra-lib-dirs=..\relative\path\to\icu\lib64 --extra-include-dirs=..\relative\path\to\icu\include text-icu This fails with: Warning: 'extra-lib-dirs: ../relative/path/to/icu/lib64' directory does not exist. Warning: 'include-dirs: ../relative/path/to/icu/include' directory does not exist. cabal: Missing dependencies on foreign libraries: * Missing C libraries: icuuc, icuin, icudt Note: The same problem occurs if you copy the ICU folders into the source tree. That just gets rid of the warnings that sdist won't work. ***Problem #2 (major): segfault! cabal install --extra-lib-dirs=C:\absolute\path\to\icu\lib64 --extra-include-dirs=C:\absolute\path\to\icu\include text-icu cabal install Now, place .cabal-sandbox\bin\test-text-icu.exe together with the 3 DLLs icudt54.dll, icuin54.dll, and icuuc54.dll from icu\bin64 all together in the same folder. Run test-text-icu. Kaboom! Note: The same problem occurs if you place *all* of the DLLs from icu\bin64 in the folder together with the exe. So it's not a missing DLL. Thanks, Yitz

1 1

Linker change in GHC 7.8 leads to widespread issues
by Bryan O'Sullivan 05 Dec '14

05 Dec '14

Hi folks, It seems that something somewhere in linker-land changed in GHC 7.8 such that packages that include C components now need to be built with position-independent code on some platforms. This affects a number of my packages. I am not sure whether the correct fix is to pepper all of these packages (and presumably dozens to hundreds of other packages on Hackage) with "-fPIC" and issue new releases, or to instead teach Cabal to do this. It would certainly be vastly less disruptive to all of the affected package authors to have Cabal automatically do the right thing here. Could someone who's closer to both piles of code please suggest which approach they believe is more appropriate?

7 11

Re: Linker change in GHC 7.8 leads to widespread issues
by Johan Tibell 04 Dec '14

04 Dec '14

I've merged the patches into the 1.20 branch. Look forward to a patch release this weekend. On Thu, Dec 4, 2014 at 1:43 PM, Yitzchak Gale <gale(a)sefer.org> wrote: > Bryan O'Sullivan wrote: > >> It seems that something somewhere in linker-land > >> changed in GHC 7.8 such that packages that include > >> C components now need to be built with > >> position-independent code on some platforms... > >> I am not sure whether the correct fix is to pepper… > >> packages... with "-fPIC"... or to instead teach Cabal > >> to do this. > > Aha! Thanks for this explanation of what I have been > suffering from. > > Mikhail Glushenkov wrote: > > I've now fixed this issue in Cabal HEAD and also pushed the fix to > > 1.20 and 1.18 branches. 1.20 and 1.18 point releases should be out > > soon. > > Thanks a million for the speedy response to this > serious issue! > > I can't wait for the point releases. I'll go with HEAD on one > of the branches for now. > > -Yitz > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >

1 0

Ready to make release candidates for 1.18 and 1.20 bugfix releases
by Johan Tibell 04 Dec '14

04 Dec '14

Hi! I believe I have merged all the fixes people wanted to see in 1.18 and 1.20. Anyone who's interested please double-check that your fixes are in: 1.18: https://github.com/haskell/cabal/compare/cabal-install-v1.18.0.5...1.18 1.20: https://github.com/haskell/cabal/compare/cabal-install-v1.20.0.3...1.20 If everyone are happy with these, I will try to make some releases this weekend. -- Johan

3 4

Re: Linker change in GHC 7.8 leads to widespread issues
by Miëtek Bak 03 Dec '14

03 Dec '14

I agree, and I’m hoping to help improve these matters with my project, Halcyon (https://halcyon.sh/) Halcyon allows all build-time and run-time dependencies of an application to be explicitly declared and installed with a single invocation. This builds on the great work done recently in Cabal to get us `cabal freeze`, and works around many long-standing Cabal issues, such as the inability to automatically install missing build-tools. Halcyon can also be used to restore entire Haskell installations in seconds, and supports GHC versions including 7.8.3, 7.8.2, 7.6.3, 7.6.1, 7.4.2, 7.2.2, and 7.0.4. Hopefully, being able to swap GHC versions in and out, without needing to have them on disk, should help lessen the amount of work needed for comprehensive testing. I am currently putting the final touches on my project before announcement. Please let me know what you think. -- Miëtek On 2014-12-03, at 18:25, Howard B. Golden <howard_b_golden(a)yahoo.com> wrote: > Hi, > > There aren't more complaints because most people haven't tried 7.8 seriously yet. (I didn't notice the problem since I've only been using GHC 7.8 under Windows.) This points out the need for some sort of regular testing of canaries (full systems producing known results) to test the entire toolchain including common libraries (HP, perhaps) and Cabal. > > At the risk of antagonizing the developers again, I will point out that there is a bit of disconnect between GHC developers, Cabal developers, library developers and users (application developers). Without slowing the GHC developers' creativity, there is a need to look at the experience of the application developers. FWIW, my sense is that there is too much turbulence for many potential application developers to adopt Haskell as their production platform unless they have significant in-house resources to deal with the rapid changes. (As as thought experiment, how many changes have to be made to Real World Haskell's programs to get them to run?) > > > Howard > > > > ----- Original Message ----- > From: Simon Marlow <marlowsd(a)gmail.com> > To: Miëtek Bak <mietek(a)bak.io>; Carter Schonwald <carter.schonwald(a)gmail.com> > Cc: "cabal-devel(a)haskell.org" <cabal-devel(a)haskell.org>; "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Sent: Wednesday, December 3, 2014 4:03 AM > Subject: Re: Linker change in GHC 7.8 leads to widespread issues > > I'm actually rather surprised we got away without doing this up to now. > Why haven't there been more complaints? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

feedback for changes to the commandline documentation/help, please
by lennart spitzner 18 Nov '14

18 Nov '14

https://gist.github.com/lspitzner/36321a9f074cb9b897ac or is there a better process? should i pull-request or open a ticket? Lennart

2 1

Where to put these flags?
by Sven Heyll 02 Nov '14

02 Nov '14

Hi List I am currently adding cabal-install flags tell cabal-install how to compile the setup program (in case the "external method" is used. Now what should I do? Should I ... a) extend global flags? b) extend only ConfigExFlags? (which means users cannot cross-compile without explicitly calling 'configure', OTOH users can set these values in cabal config file) c) continue to add a set of flags to every command? My preferences: (b) > (c) > (a). What do you think? With best regards Sven Heyll

2 1

New fields/flags and semantics for GHCJS
by Luite Stegeman 31 Oct '14

31 Oct '14

Hi all, I've been maintaining a Cabal fork for GHCJS. The GHCJS-specific bits have been relatively stable for a while now, and are feature complete, apart from a few small features that I'll complete later this week. So I think it's time to discuss merging the branch. This discussion is for the user visible changes only, the implementation details can be discussed later when the code has been cleaned up for the merge (1-2 weeks). I hope that the proposed changes cover most JavaScript packaging/build requirements, but feature requests or questions about support for specific scenarios are welcome! First some background: GHCJS is a cross-compiler, installed as a package. It has its own version number (0.1.0 currently), independent of the GHC version it was built with. After GHCJS and its standard libraries have been installed, it does not require GHC anymore. Cabal's custom setup type is supported by compiling Setup.hs to JavaScript and running it with node.js. In the Cabal branch, GHCJS is treated as a very close relative of GHC. In various places there is support for GHCJS building native code. While this (--native-too mode) is currently disabled in a default installation, it can be enabled again for generating JavaScript and native code from the same Core, for example to allow closure serialization and continuing computations between client and server (not yet implemented!). All Cabal features are supported, including sandboxes. "cabal test" compiles the testsuite of a package and runs it with node.js. "cabal repl" is implemented on the Cabal side, but there is no repl for GHCJS yet, this is planned for the not too far future (with a terminal and browser based front end). The changes: # a new implementation flag: impl(ghcjs) A new implementation flag has been added for GHCJS, using the GHCJS version number. Since GHCJS is a close descendant of GHC, the impl(ghc) flag is also set when something is being built with GHCJS. For example if impl(ghc >= 7.2) -- GHC.Generics support (compiler could be GHCJS) if impl(ghcjs >= 0.1) -- package is being built with GHCJS # ghcjs-options, ghcjs-shared-options, ghcjs-prof-options These new fields behave similar to those for GHC (ghcjs-shared-options only has effect for native-too mode). If not set, the corresponding value from ghc-options, ghc-shared-options, ghc-prof-options is used. (An alternative is to let ghcjs-*-options field append the options to the corresponding ghc-*-options field, instead of replacing them) # new js-sources field A js-sources field is treated like the c-sources field. JS sources of all dependencies of a an executable are collected into a big JavaScript file. GHCJS also outputs some data about the collected files for custom deployment scripts. JS sources are not compiled, but are run through the C preprocessor. Since running the same file through the preprocessor twice is problematic, and it's very useful to be able to set some preprocessor options at link time (for example -DGHCJS_BROWSER, which removes node.js-specific code), the strategy is as follows: - When a library is being installed, the js-sources are copied to the library installation directory, but not run through the preprocessor. the cpp options are saved in the installation dir - When building an executable, the JS-sources are collected. Each JS source is processed with its own saved cpp-options with the cpp-options for building the executable appended. # new JavaScriptFFI extension The extension has been in GHC since 7.8, but it can't be used on non-JavaScript code generators. This change just adds it to the list of known extensions. luite

2 4

improving commandline documentation/help
by lennart spitzner 30 Oct '14

30 Oct '14

hello cabal devs, i am willing to put a bit of time into improving the help texts of cabal-install. some questions: 1) nobody else is working on this, right? is there risk that it interferes with other's work? (i'd basically touch Distribution.Simple.Command and the different fooCommand's in both Setup.hs's) 2) is there a specific reason that the help texts currently are so short, other than lack of time/focus on functionality? pending large changes or smth? 3) is there a policy to keep commits touching Cabal and cabal-install subdirectories separate (for git-subtree purposes, for example)? Lennart

2 1

passing CFLAGS and LDFLAGS to ghc via Cabal?
by Jens Petersen 27 Oct '14

27 Oct '14

Hi, This may seem like a strange question since most ghc compilation uses the NCG or llvm backends, but I want to ask about how/if one can pass CFLAGS/LDFLAGS to gcc from Cabal? So far I tried using --gcc-options="$RPM_OPT_FLAGS" (and also just exporting CFLAGS), but as far as I can tell (from --ghc-option=-v) the options are not passed by ghc to gcc. Is the problem that ghc first compiles C code to assembler before compiling the asm to an object file? (This is in the context of adding of trying to add debuginfo for C files to Fedora's Haskell packages, though I am not even sure if it is useful. Maybe it is a futile experiment?) Jens

2 3