Error building on Nix.

[deech]

/u/taktoa on Reddit reported:

I'm trying to get this to build in Nix, and I'm getting the following linker error:

Linking dist/build/fltkhs-fluidtohs/fltkhs-fluidtohs ...
…/dist/build/libHSfltkhs-0.5.1.4-…-ghc8.0.1.so: undefined reference to `Fl_Timer_New'
…/dist/build/libHSfltkhs-0.5.1.4-…-ghc8.0.1.so: undefined reference to `Fl_OverriddenFile_Browser_New'
…/dist/build/libHSfltkhs-0.5.1.4-…-ghc8.0.1.so: undefined reference to `Fl_File_Browser_New'
…/dist/build/libHSfltkhs-0.5.1.4-…-ghc8.0.1.so: undefined reference to `Fl_OverriddenFile_Browser_New_WithLabel'
…/dist/build/libHSfltkhs-0.5.1.4-…-ghc8.0.1.so: undefined reference to `Fl_OverriddenTimer_New'
…/dist/build/libHSfltkhs-0.5.1.4-…-ghc8.0.1.so: undefined reference to `Fl_File_Browser_New_WithLabel'
collect2: error: ld returned 1 exit status
`g++' failed in phase `Linker'. (Exit code: 1)

Any idea why that would be happening? Usually in my experience it results from modules not being in exposed-modules but that should cause failures on any platform.

The Nix expression I'm using is: haskell.lib.addBuildTools (self.callPackage ./fltkhs.nix {}) [autoconf fltk mesa libjpeg] where fltk.hs contains the output of cabal2nix cabal://fltkhs.

[taktoa]

Thanks for making an issue, I'll investigate this more a little later; the obvious first question to ask is what is exporting the symbols Fl_* mentioned in the linker error, though the lack of mangling implies that it they are likely symbols from fltk itself, rather than being symbols exported by fltkhs.

Also, I just noticed a typo in my description; I meant to write "where fltkhs.nix contains the output of cabal2nix cabal://fltkhs", not "where fltk.hs contains ...".

[deech]

I have a guess as to why the problem is occuring but don't have a fix because I don't know Nix. When building fltkhs, the C bindings are built separately, their location is added to the library path and copied over manually to the same lib directory where the Haskell library is installed. Seems like Nix is not able to see the C bindings.

In fact if you want to see what it's doing you can build the C parts by just doing autoconf;./configure;make at the root of the project. You should see a new directory c-lib has been added containing the shared and static version of the C bindings and two other directories {shared,static}_object_files containing the *.o object files. You can get rid of them with make clean.

The reasons for the added complexity is that eventually I want to split off the C part into it's own project. I have a number of demos written in C that depend on it.

Is there a way to tell Nix to depend on a library that will be built over the course of the current build?

[taktoa]

Oh, I see. To be honest, projects that use the default Cabal Setup.hs are drastically more likely to work out of the box with Nix (and in many other situations, IME). The easiest path forward then would probably be to wait for you to split off the C bindings into a separate project (presumably this would just be a simple autoconf C-only project that ideally produces a pkg-config file that fltkhs can depend on?), and then the Haskell side would just be a normal Cabal project with a simple Setup.hs.

Fixing the autogenerated Nix package for such a Haskell package would be simple: create a Nix package for the C bindings (call it fltk-c), and then do self.callPackage ./fltkhs.nix { fltk-c-1 = fltk-c; }), where fltk-c-1 is the argument autogenerated by cabal2nix corresponding to the pkg-config dependency given in fltkhs.cabal file. In theory this separation of packages could be done without any upstream changes, though upstream changes would probably make it more convenient (I'd have to patch Setup.hs otherwise).

[deech]

Sounds good. I'll leave this issue open as a placeholder.

[deech]

I got something working on the Nix branch. Do you mind pulling and trying? It worked for me with nix-build -A fltkhs.

[taktoa]

@deech wow, that was a shockingly quick turnaround on learning Nix :^)

I tried building the code in the Nix branch but it ended up having an absurd number of "multiple definition of ..." errors.

Here's the full build output: https://gist.github.com/taktoa/367b0877de340d25422bc54628a5c7c6

[deech]

What platform are you on? Guessing OSX?

[taktoa]

Nope, I'm on NixOS. Would you like me to rerun the build teed into a log file?

[deech]

Yes, please. :) I just installed Nix via the curl command on the website and everything goes into my ~/.nix-profile I think.

[taktoa]

Here's the log (27 MiB uncompressed, 1.8 MiB compressed): fltkhs.log.gz

[deech]

Oh wow. Thanks!

[deech]

I'm not sure what's going on but I'm unable to reproduce. I don't have NixOS installed but starting from a fresh install of Ubuntu Mate 15.10 my steps were:

$ curl https://nixos.org/nix/install | sh
$ nix-env -i cabal2nix
$ nix-env -i cabal-install
$ git clone http://github.com/deech/fltkhs -b Nix
$ cd fltkhs
$ nix-build -A fltkhs

[taktoa]

Interesting, I'll look into it a bit more later.

For reference, though, the Git revision of nixpkgs I'm building against is 0cb2838d8cd4. I do have a pretty extensively modified nixpkgs configuration, but since you're passing the config attribute into import <nixpkgs> those overrides shouldn't be taking effect.

[taktoa]

BTW: <nixpkgs> is just a special kind of path literal in Nix; if you git clone nixpkgs into ./foo, then you can import ./foo { config = ... } to build against that version of nixpkgs instead.

[deech]

These may not be fixed in the latest version 0.5.2.5. Can you try again?

[sboosali]

@taktoa any update?

[sboosali]

Any update? I don't see the nix branch, or a nix file I can try out. I'd like to help it get it to work with nix.

[deech]

I have a Nix branch. It hasn't been touched in a while so I brought it up to date with master. Any help here is appreciated.

[sboosali]

@taktoa

btw, fltk-config itself works on NixOS right?

I can build a simple c examples with nix-shell --pure, and it probably builds cross-platform anyways, but I just want to check. e.g.

git clone https://github.com/sboosali/fltkhs-reflex-host
cd fltkhs-reflex-host/c
./build.sh
# should open a window

https://github.com/sboosali/fltkhs-reflex-host/blob/master/c/default.nix

[taktoa]

@sboosali Yup, seems to work on my NixOS 17.09 machine.

[sboosali]

@taktoa

can you check if the new fltkhs nix file works? I'm new to nix, but I think works for me in a pure shell too (but I can't test now, I think you have to add cabal-install as a build tool during development or something).

git pull && cabal clean # or clone 
nix-shell # --pure ?

# defaults flags should work
cabal configure 
cabal build
cabal run fltkhs-buttons 

[mrkgnao]

@sboosali

The C demo works for me, but the fltkhs-buttons thing just returns without displaying anything.

[samlich]

I've separated the C out at https://github.com/TheSandwichMakr/fltkc and https://github.com/TheSandwichMakr/fltkhs

It builds for me using nixpkgs-channel rev 4b649a99d8461c980e7028a693387dc48033c1f7 from the nixos github and ghcHEAD (not that you need the newer packages).

I changed the opengl support to default to true, and the output libraries go into shared/static_object_files. The all target builds the regular .so rather than the one with the -dyn suffix. fltkhs also links dynamically to fltkc now.

The changes may not be so friendly to other operating systems, but adding an install target will probably be the main fix, idk.

[sboosali]

@deech

btw, how much of the custom setup.hs does stuff for -fbundled? That is, without it, can it use:

build-type: Configure

or

build-type: Make

? Or does it need to do more for the c2hs / other stuff?

On Wed, Jun 20, 2018, 1:54 PM TheSandwichMakr [email protected] wrote:

I've separated the C out at https://github.com/TheSandwichMakr/fltkc and https://github.com/TheSandwichMakr/fltkhs

It builds for me using nixpkgs-channel rev 4b649a99d8461c980e7028a693387dc48033c1f7 from the nixos github and ghcHEAD (not that you need the newer packages).

I changed the opengl support to default to true, and the output libraries go into shared/static_object_files. The all target builds the regular .so rather than the one with the -dyn suffix. fltkhs also links dynamically to fltkc now.

The changes may not be so friendly to other operating systems, but adding an install target will probably be the main fix, idk.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/53#issuecomment-398893376, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMVnvt7aVtc04nUcXj3ws8GFNSHRZks5t-raFgaJpZM4Mah-j .

[deech]

A bunch of it is dedicated to bundled builds, generally anything under an if (bundledBuild flags) (https://github.com/deech/fltkhs/blob/master/Setup.hs#L117).

There is also a fair amount dedicated to Windows.