LGPL licensing restrictions on Windows because of integer-gmp #399

Closed
quyse opened this Issue Jun 24, 2015 · 93 comments

Projects

None yet
@quyse
Contributor
quyse commented Jun 24, 2015

Default version of GHC on Windows produces binaries with integer-gmp linked statically. As integer-gmp's license is LGPL, it means that resulting binaries should be provided with source code or object files. I guess that's not a thing everyone would want.

On UNIXes integer-gmp is linked dynamically, so these restrictions don't apply.

So, in order to fix that we can either:

  • Provide a version of GHC which builds Windows executables with integer-gmp linked dynamically (haven't tried, but seems like it's possible).
  • Provide a version of GHC with integer-simple wired in instead of integer-gmp (some packages have problems, but overall works good for me).
  • Or at least write a big red warning on stack's homepage that your Haskell software on Windows has to be essentially a free software.

Additional Links:
ReplacingGMPNotes

UPDATE:

@vyp
Contributor
vyp commented Jun 24, 2015

Might help: http://copyleft.org/guide/comprehensive-gpl-guidech12.html#x15-11100011.5

N.B. Have no idea if that website/document can be considered legal advice.

@andrewthad

I would love it if there was a way to use integer-simple with stackage. As a warning, blaze-textual, which is supported by stackage, has a very long standing issue that prevents it from working with integer-simple (and this library is used by postgres-simple, which is used by a lot of people). If stackage were to start supporting integer-simple GHC builds, some packages would have to get patched first.

@snoyberg
Contributor

I don't think a big red warning is the right answer, but having this well documented in the FAQ seems reasonable. I would love to get rid of the LGPL code entirely, but as @andrewthad points out, there's no real chance of being able to do that right now.

@quyse Would you be able to add a FAQ entry for this?

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jun 25, 2015
@kantp
Contributor
kantp commented Jun 25, 2015

Having the option of using integer-simple (without compiling ghc oneself) for those projects that do not rely on integer-gmp would be a nice convenience, and greatly appreciated.

@snoyberg
Contributor

I have no objection to adding such support. Would someone be able to build
Windows bindists for that?

On Thu, Jun 25, 2015, 9:40 AM Philipp notifications@github.com wrote:

Having the option of using integer-simple (without compiling ghc oneself)
for those projects that do not rely on integer-gmp would be a nice
convenience, and greatly appreciated.


Reply to this email directly or view it on GitHub
#399 (comment)
.

@kantp
Contributor
kantp commented Jun 25, 2015

I guess if I want the feature, it's only fair if I provide the windows binaries :-)

Which versions of ghc does stack support? 7.8.4 onwards, or also earlier?

@snoyberg
Contributor

It theoretically supports any version requested by the user, but 7.8.4 and
on is probably what people care about.

On Thu, Jun 25, 2015, 12:26 PM Philipp notifications@github.com wrote:

I guess if I want the feature, it's only fair if I provide the windows
binaries :-)

Which versions of ghc does stack support? 7.8.4 onwards, or also earlier?


Reply to this email directly or view it on GitHub
#399 (comment)
.

@quyse
Contributor
quyse commented Jun 25, 2015

@snoyberg I've added a short entry to the FAQ pointing to this issue.

By the way, I was thinking it's Windows-only limitation, as I've checked that on Linux GMP is linked dynamically. But now I found this comment which made me worried about OS X. I don't work with OS X, does anyone know about the situation there?

@snoyberg
Contributor

@quyse Thanks!

@snoyberg
Contributor

@kantp Has provided the following GHC bindists:

My thought is that we would add a new command line option that- like --arch- would control which GHC to use. Either that, or have a fake OS of windowsnolgpl or something like that. What would help with getting this moving is if others could test out these bindists and report results.

@quyse
Contributor
quyse commented Jun 25, 2015

@snoyberg @kantp That's great, thanks for getting back so quickly! I just tested your GHC (only 7.10.1 for the moment), and I was able to build and run my project which uses about 30 packages, and I wasn't able to build my another project because of issue with network. Quick notes:

  • Three packages in my experiment required special care, those are cryptonite, hashable and text. They all have configure flags to disable use of integer-gmp. hashable also has a fix on its github which isn't uploaded to hackage yet, so I had to put it locally. Here is excerpt of stack.yaml worked for me:
resolver: nightly-2015-06-23
arch: x86_64
extra-deps: ['cryptonite-0.5', 'hashable-1.2.3.2', 'text-1.2.1.1']
flags:
  cryptonite:
    'integer-gmp': false
  hashable:
    'integer-gmp': false
  text:
    'integer-simple': true
packages:
- '../../thirdparty/tibbe-hashable'
  • I wasn't able to use network package because of well-known issue with it:
Configuring network-2.6.2.0...
Setup.hs: The package has a './configure' script. This requires a Unix
compatibility toolchain such as MinGW+MSYS or Cygwin.

Usually I workaround this by using cabal install network --configure-option --build=x86_64-w64-mingw32 in Cygwin, but this time it doesn't work, as there's no cabal, and I wasn't able to construct some similar command line with stack instead of cabal, getting the same error. The strange thing is that with default GHC-7.10.1 downloaded by stack setup it installs network without any trouble (and without using Cygwin). I was setting up custom GHC by just placing it in PATH:

set PATH=D:\programs\ghc-7.10.1\bin;D:\programs\ghc-7.10.1\mingw\bin;D:\programs\ghc-7.10.1\mingw\x86_64-w64-mingw32\bin;D:\programs\ghc-7.10.1\mingw\libexec\gcc\x86_64-w64-mingw32\4.6.3;

Am I missing something?

@snoyberg
Contributor

stack typically solves this by including PortableGit's msys implementation on the PATH, which will allow configure scripts to run. Can you try adding that and trying again?

@3noch 3noch referenced this issue in tibbe/hashable Jun 26, 2015
Closed

Upload integer-simple fix #99

@3noch
Member
3noch commented Jun 26, 2015

Would it make sense to add a custom "arch" or "os" for GHC's built with no gmp-integer? You could minimally support the last two GHC versions on whatever OS you have a build for. In other words, could you add an "os" that's "windows-no-gmp" for the time being? Or perhaps add it to the arch? That would basically make stack the single best way to get a commercial-haskell GHC.

@3noch 3noch referenced this issue in ndmitchell/shake Jun 26, 2015
Closed

Shake not friendly to commercial builds #272

@3noch
Member
3noch commented Jun 26, 2015

Just realized you already had that idea. I'm all for it, or something like it.

@3noch
Member
3noch commented Jun 26, 2015

If I can get builds working, I'll supply as many builds for Windows as my machine can crank out. This applies to MinGHC too.

@3noch 3noch referenced this issue in fpco/minghc Jun 26, 2015
Closed

Support no gmp builds #72

@hvr
hvr commented Jun 26, 2015

Minor note:

https://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes is kinda obsolete as the GMP library was rewritten from scratch for GHC 7.10 (https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2),

Personally, I'd like to get rid of integer-simple altogether (to avoid having different surface APIs, and avoid all that conditional CPP/cabal-flag mess we have right now), and rather be able to select the integer-gmp backend at link-time in the same way you can switch between e.g. the threaded and the non-threaded runtime. Therefore allow you to say e.g. ghc --make -O -finteger-library=bsdnt Hello.hs and then not link the GMP into your binary, but rather e.g. a bsdnt based implementation of the integer-gmp primitives. It's not difficult to implement... but as usual time is a scarce resource :-/

/cc @thoughtpolice

@kantp
Contributor
kantp commented Jun 26, 2015

@hvr That sounds like the Right Thing to do, very nice.

In the meantime, if there is a switch for the integer library, I think it would make sense to have this orthogonal to the choice of the operating system.

@3noch
Member
3noch commented Jun 26, 2015

@quyse hashable was just updated, now for a stackage release including it.

@3noch
Member
3noch commented Jun 26, 2015

@snoyberg... Wow. You don't miss a beat. Stackage part already being done

@snoyberg
Contributor

I can't take credit, it's just the daily Stackage builds doing their thing.

IIUC, this means that the LGPL concern will not apply to the normal GHC bindist in the near future. Is that the case? I should probably say that IANAL, so some of this goes over my head. Perhaps we can have a thread on ghc-dev about this, I'd definitely like to understand this better and understand what work still needs to be done.

@hvr
hvr commented Jun 26, 2015

@snoyberg feel free to start a thread, I'll chime in and try to answer as best as I can any questions you put forward

@tejon
Contributor
tejon commented Jun 26, 2015

Hackage says the license is BSD3, and it says so for both versions...

@quyse
Contributor
quyse commented Jun 26, 2015

@tejon Sorry, I just added an update to the first post with clarification about integer-gmp and GMP. I was using names integer-gmp and GMP interchangeably.

@quyse
Contributor
quyse commented Jun 26, 2015

@snoyberg Yes, finally I was able to install network from MSYS command line, thanks for help! For me everything works now. As a side note, maybe it's worth to implement --with-compiler setting similar to cabal's? It would be more convenient to use non-standard compiler rather than manually adding it to PATH, and stack would treat it in the same way as automatically installed ones, i.e. add msys and stuff.

@3noch Cool, that's fast :)

@3noch
Member
3noch commented Jun 26, 2015

So all we need to do is not link in integer-gmp? No special build of GHC required?

@3noch
Member
3noch commented Jun 26, 2015

@snoyberg How do you come to the conclusion "IIUC, this means that the LGPL concern will not apply to the normal GHC bindist in the near future." Are you assuming that folks who need this feature (I'm one!) will just install custom builds of GHC?

@snoyberg
Contributor

I understood Herbert as saying replacing the LGPL library with something
else would become a link time option, in which case we'd all be using the
same GHC and just changing the linker flags when desired.

On Fri, Jun 26, 2015, 3:31 PM Elliot Cameron notifications@github.com
wrote:

@snoyberg https://github.com/snoyberg How do you come to the conclusion
"IIUC, this means that the LGPL concern will not apply to the normal GHC
bindist in the near future." Are you assuming that folks who need this
feature (I'm one!) will just install custom builds of GHC?


Reply to this email directly or view it on GitHub
#399 (comment)
.

@3noch
Member
3noch commented Jun 26, 2015

I see your point. In future GHC releases this will be solved in a nice way. But we still need to get custom builds of 7.8.4, 7.10.1, etc.

@snoyberg
Contributor

If we can get it into 7.10.3, I'd consider it good enough to be honest. It
seems that even with 7.10.1 we should be able to do something better than
reverting to integer-simple.

On Fri, Jun 26, 2015, 3:43 PM Elliot Cameron notifications@github.com
wrote:

I see your point. In future GHC releases this will be solved in a nice
way. But we still need to get custom builds of 7.8.4, 7.10.1, etc.


Reply to this email directly or view it on GitHub
#399 (comment)
.

@3noch
Member
3noch commented Jun 26, 2015

I'm all ears for what could be done with 7.10.1. I'm under the impression it's still in the same boat as 7.8.4, albeit with a better implementation of GMP.

@3noch
Member
3noch commented Jun 26, 2015

This actually correlates to the issue with stack only looking at the first GHC on the PATH. If I were to install a custom build of for both 32-bit and 64-bit GHC and put them on my PATH, stack would only ever find one of them. At that point my only option is to switch between the two GHCs outside of stack and tell stack which architecture to expect.

@3noch
Member
3noch commented Jun 26, 2015

Correction, I probably would not need to tell stack which architecture to expect since it wouldn't be relying on its own installations of GHC at all.

@3noch
Member
3noch commented Jun 26, 2015

If I supplied builds for Windows, would you even consider hosting them so stack can use them directly? That would still require some sort of hack (or feature) to tell stack to use the custom ones.

@snoyberg
Contributor

I have no problem with that. My big concern with integer-simple is that it
will be incapable of building lots of projects

On Fri, Jun 26, 2015, 6:25 PM Elliot Cameron notifications@github.com
wrote:

If I supplied builds for Windows, would you even consider hosting them so
stack can use them directly? That would stick require some sort of hack
(or feature) to tell stack to use the custom ones.


Reply to this email directly or view it on GitHub
#399 (comment)
.

@3noch
Member
3noch commented Jun 26, 2015

Yes, that's true. However, when it matters, LGPL is a deal-breaker and libraries can often be patched/replaced.

@kantp
Contributor
kantp commented Jun 26, 2015

@3noch Absolutely.

@Jookia
Jookia commented Jun 26, 2015

Uhh, the statically linking the LGPL doesn't mean your software has to be free - you just have to ship your object files so users can replace the LGPLed portions.

@3noch
Member
3noch commented Jun 30, 2015

@kantp or anyone else willing to help me get GHC building? I'm having troubles 😢 http://lpaste.net/135610

@kantp
Contributor
kantp commented Jul 1, 2015

Since it was mentioned here by @andrewthad, that issue in blaze-textual has just been resolved, and blaze-textual-0.2.1.0 supports integer-simple.

@andrewthad

woot!

@3noch
Member
3noch commented Jul 1, 2015

@kantp Are you able to provide 32-bit versions the bindists you already supplied? I'm having a hard time getting working GHC builds.

@kantp
Contributor
kantp commented Jul 2, 2015

@3noch Sorry, I just noticed your comment above I didn't respond to. Was that failed build on a 32 bit machine?

@3noch
Member
3noch commented Jul 2, 2015

@kantp My first attempts at building were for 64-bit. Once I got the build to finish I moved on to 32-bit since those are the remaining builds we need before stack can fully support both LTS 2 and nightly with as integer-simple version. I was building 32-bit on a 64-bit machine and realized that the build system was getting quite confused. I'm about to start over on a 32-bit VM in hopes it doesn't get confused. However, if you already have everything setup for these builds, you can produce them much faster than I can (plus I don't really know what I'm doing...yet!). I'll keep trying until I get something working or someone else beats me to it.

P.S. That build error was due to a bug in the build script which was solved by cherry-picking some future commit (@ezyang pointed me to that solution in ghc-devs).

@snoyberg snoyberg modified the milestone: 0.2.0.0, 0.3.0.0 Jul 2, 2015
@3noch
Member
3noch commented Jul 2, 2015

Ok I have a build of 32-bit GHC 7.10.1 with integer-simple. Now working on 32-bit 7.8.4. @snoyberg We now have enough to at least support this natively for nightly snapshots. I imagine the backend work is pretty straightforward.

@3noch
Member
3noch commented Jul 2, 2015

If we support nightly snapshots at this point, other resolvers will simply report that GHC is not available for that OS/arch/whatever.

@3noch
Member
3noch commented Jul 2, 2015

They can be added after the fact without any new releases.

@3noch
Member
3noch commented Jul 2, 2015

@snoyberg The 32-bit build is temporarily hosted here.

@snoyberg
Contributor
snoyberg commented Jul 2, 2015

I've also just pushed the fake OS windowsintegersimple so that a command like stack build --os windowsintegersimple should pull the right image. I'm doing some testing, though others are welcome to give it a shot too.

@3noch
Member
3noch commented Jul 3, 2015

Do you care if I keep the doc folder in these bindists? I doubt folks will be referring to the mostly broken docs in a privately maintained stack folder.

@snoyberg
Contributor
snoyberg commented Jul 3, 2015

I have no opinion on the matter. Since you're driving the usage of this right now, I'd say trust your judgement regarding what functionality is necessary.

@3noch
Member
3noch commented Jul 3, 2015

Ok, I'll probably get rid of it since it will make the files smaller.

@3noch
Member
3noch commented Jul 3, 2015

With windowsintegersimple as the OS, it looks like stack is deducing that I need unix to be built, which obviously fails:

> stack build
th-lift-0.7.2: configure
old-time-1.1.0.3: configure
th-lift-0.7.2: build
th-lift-0.7.2: install
utf8-string-1: configure
old-time-1.1.0.3: build
mtl-2.2.1: configure
utf8-string-1: build
js-flot-0.8.3: configure
mtl-2.2.1: build
syb-0.4.4: configure
old-time-1.1.0.3: install
js-flot-0.8.3: build
utf8-string-1: install
unix-2.7.1.0: configure
syb-0.4.4: build
js-flot-0.8.3: install
mtl-2.2.1: install
syb-0.4.4: install
text-1.2.1.1: configure
unix-2.7.1.0: build
happy-1.19.5: configure
text-1.2.1.1: build
th-expand-syns-0.3.0.6: configure
happy-1.19.5: build
th-expand-syns-0.3.0.6: build
th-expand-syns-0.3.0.6: install
happy-1.19.5: install
text-1.2.1.1: install
Progress: 10/27
--  While building package unix-2.7.1.0 using:
      C:\\Users\\Elliot Cameron\\AppData\\Roaming\\stack\\programs\\i386-windowsintegersimple\\ghc-7.10.1\\bin\\runhask
ll.exe -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package-db=C:\Users\Elliot Cameron\AppData\Roaming
stack\snapshots\i386-windowsintegersimple\nightly-2015-07-02\7.10.1\pkgdb\ C:\Users\ELLIOT~1\AppData\Local\Temp\stack12
04\unix-2.7.1.0\Setup.hs --builddir=.stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\ build
    Process exited with code: ExitFailure 1
    Logs have been written to: "C:\\Code\\windows-client\\.stack-work\\logs\\unix-2.7.1.0.log"

    Configuring unix-2.7.1.0...
    configure: WARNING: unrecognized options: --with-compiler, --with-gcc
    checking for gcc... gcc
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.exe
    checking for suffix of executables... .exe
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether gcc accepts -g... yes
    checking for gcc option to accept ISO C89... none needed
    checking how to run the C preprocessor... gcc -E
    checking for grep that handles long lines and -e... /usr/bin/grep
    checking for egrep... /usr/bin/grep -E
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking dlfcn.h usability... no
    checking dlfcn.h presence... no
    checking for dlfcn.h... no
    checking for an ANSI C-conforming const... yes
    checking for special C compiler options needed for large files... no
    checking for _FILE_OFFSET_BITS value needed for large files... unknown
    checking for _LARGE_FILES value needed for large files... unknown
    checking dirent.h usability... yes
    checking dirent.h presence... yes
    checking for dirent.h... yes
    checking fcntl.h usability... yes
    checking fcntl.h presence... yes
    checking for fcntl.h... yes
    checking grp.h usability... no
    checking grp.h presence... no
    checking for grp.h... no
    checking limits.h usability... yes
    checking limits.h presence... yes
    checking for limits.h... yes
    checking pwd.h usability... no
    checking pwd.h presence... no
    checking for pwd.h... no
    checking signal.h usability... yes
    checking signal.h presence... yes
    checking for signal.h... yes
    checking for string.h... (cached) yes
    checking sys/resource.h usability... no
    checking sys/resource.h presence... no
    checking for sys/resource.h... no
    checking for sys/stat.h... (cached) yes
    checking sys/times.h usability... no
    checking sys/times.h presence... no
    checking for sys/times.h... no
    checking sys/time.h usability... yes
    checking sys/time.h presence... yes
    checking for sys/time.h... yes
    checking sys/utsname.h usability... no
    checking sys/utsname.h presence... no
    checking for sys/utsname.h... no
    checking sys/wait.h usability... no
    checking sys/wait.h presence... no
    checking for sys/wait.h... no
    checking bsd/libutil.h usability... no
    checking bsd/libutil.h presence... no
    checking for bsd/libutil.h... no
    checking libutil.h usability... no
    checking libutil.h presence... no
    checking for libutil.h... no
    checking pty.h usability... no
    checking pty.h presence... no
    checking for pty.h... no
    checking utmp.h usability... no
    checking utmp.h presence... no
    checking for utmp.h... no
    checking termios.h usability... no
    checking termios.h presence... no
    checking for termios.h... no
    checking time.h usability... yes
    checking time.h presence... yes
    checking for time.h... yes
    checking for unistd.h... (cached) yes
    checking utime.h usability... yes
    checking utime.h presence... yes
    checking for utime.h... yes
    checking for getgrgid_r... no
    checking for getgrnam_r... no
    checking for getpwnam_r... no
    checking for getpwuid_r... no
    checking for getpwnam... no
    checking for getpwuid... no
    checking for getpwent... no
    checking for getgrent... no
    checking for lchown... no
    checking for setenv... no
    checking for sysconf... no
    checking for unsetenv... no
    checking for clearenv... no
    checking for nanosleep... no
    checking for ptsname... no
    checking for setitimer... no
    checking for readdir_r... no
    checking for telldir... yes
    checking for seekdir... yes
    checking for execvpe... yes
    checking for struct stat.st_atim... no
    checking for struct stat.st_mtim... no
    checking for struct stat.st_ctim... no
    checking for struct stat.st_atimespec... no
    checking for struct stat.st_mtimespec... no
    checking for struct stat.st_ctimespec... no
    checking for struct stat.st_atimensec... no
    checking for struct stat.st_mtimensec... no
    checking for struct stat.st_ctimensec... no
    checking for struct stat.st_atime_n... no
    checking for struct stat.st_mtime_n... no
    checking for struct stat.st_ctime_n... no
    checking for struct stat.st_uatime... no
    checking for struct stat.st_umtime... no
    checking for struct stat.st_uctime... no
    checking for struct passwd.pw_gecos... no
    checking for utimensat... no
    checking for futimens... no
    checking for lutimes... no
    checking for futimes... no
    checking for mkstemps... no
    checking for mkdtemp... no
    checking for fsync... no
    checking for fdatasync... no
    checking for posix_fadvise... no
    checking for posix_fallocate... no
    checking for library containing shm_open... no
    checking value of SIGABRT... 22
    checking value of SIGALRM... -1
    checking value of SIGBUS... -1
    checking value of SIGCHLD... -1
    checking value of SIGCONT... -1
    checking value of SIGFPE... 8
    checking value of SIGHUP... -1
    checking value of SIGILL... 4
    checking value of SIGINT... 2
    checking value of SIGKILL... -1
    checking value of SIGPIPE... -1
    checking value of SIGQUIT... -1
    checking value of SIGSEGV... 11
    checking value of SIGSTOP... -1
    checking value of SIGTERM... 15
    checking value of SIGTSTP... -1
    checking value of SIGTTIN... -1
    checking value of SIGTTOU... -1
    checking value of SIGUSR1... -1
    checking value of SIGUSR2... -1
    checking value of SIGPOLL... -1
    checking value of SIGPROF... -1
    checking value of SIGSYS... -1
    checking value of SIGTRAP... -1
    checking value of SIGURG... -1
    checking value of SIGVTALRM... -1
    checking value of SIGXCPU... -1
    checking value of SIGXFSZ... -1
    checking value of SIG_BLOCK... -1
    checking value of SIG_SETMASK... -1
    checking value of SIG_UNBLOCK... -1
    checking value of SIGINFO... -1
    checking value of SIGWINCH... -1
    checking for _SC_GETGR_R_SIZE_MAX... no
    checking for _SC_GETPW_R_SIZE_MAX... no
    checking return type of usleep... int
    checking return type of unsetenv... int
    checking for RTLD_NEXT from dlfcn.h... no
    checking for RTLD_DEFAULT from dlfcn.h... no
    checking for openpty... no
    checking for openpty in -lutil... no
    checking for openpty in -lbsd... no
    checking for /dev/ptmx... yes
    checking for /dev/ptc... no
    checking for library containing dlopen... no
    checking build system type... i686-pc-msys
    checking host system type... i686-pc-msys
    checking target system type... i686-pc-msys
    checking for library containing sem_close... no
    configure: Not found
    configure: creating ./config.status
    config.status: creating unix.buildinfo
    config.status: creating include/HsUnixConfig.h
    configure: WARNING: unrecognized options: --with-compiler, --with-gcc
    Setup.hs: Package unix-2.7.1.0 can't be built on this system.
@snoyberg
Contributor
snoyberg commented Jul 3, 2015

I know the problem, but can't fix it until tomorrow. We need to have
special handling in Stack.Package for OtherOS "windowsintegersimple" when
resolving flags. This shouldn't be too hard, want to take a crack at it?

On Thu, Jul 2, 2015, 7:05 PM Elliot Cameron notifications@github.com
wrote:

Looks like stack is deducing that I need unix to be build, which
obviously fails:

stack build
th-lift-0.7.2: configure
old-time-1.1.0.3: configure
th-lift-0.7.2: build
th-lift-0.7.2: install
utf8-string-1: configure
old-time-1.1.0.3: build
mtl-2.2.1: configure
utf8-string-1: build
js-flot-0.8.3: configure
mtl-2.2.1: build
syb-0.4.4: configure
old-time-1.1.0.3: install
js-flot-0.8.3: build
utf8-string-1: install
unix-2.7.1.0: configure
syb-0.4.4: build
js-flot-0.8.3: install
mtl-2.2.1: install
syb-0.4.4: install
text-1.2.1.1: configure
unix-2.7.1.0: build
happy-1.19.5: configure
text-1.2.1.1: build
th-expand-syns-0.3.0.6: configure
happy-1.19.5: build
th-expand-syns-0.3.0.6: build
th-expand-syns-0.3.0.6: install
happy-1.19.5: install
text-1.2.1.1: install
Progress: 10/27
-- While building package unix-2.7.1.0 using:
C:\Users\Elliot Cameron\AppData\Roaming\stack\programs\i386-windowsintegersimple\ghc-7.10.1\bin\runhask
ll.exe -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package-db=C:\Users\Elliot Cameron\AppData\Roaming
stack\snapshots\i386-windowsintegersimple\nightly-2015-07-02\7.10.1\pkgdb\ C:\Users\ELLIOT~1\AppData\Local\Temp\stack12
04\unix-2.7.1.0\Setup.hs --builddir=.stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\ build
Process exited with code: ExitFailure 1
Logs have been written to: "C:\Code\windows-client.stack-work\logs\unix-2.7.1.0.log"

Configuring unix-2.7.1.0...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking for an ANSI C-conforming const... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... unknown
checking for _LARGE_FILES value needed for large files... unknown
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... no
checking grp.h presence... no
checking for grp.h... no
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking pwd.h usability... no
checking pwd.h presence... no
checking for pwd.h... no
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking for string.h... (cached) yes
checking sys/resource.h usability... no
checking sys/resource.h presence... no
checking for sys/resource.h... no
checking for sys/stat.h... (cached) yes
checking sys/times.h usability... no
checking sys/times.h presence... no
checking for sys/times.h... no
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/utsname.h usability... no
checking sys/utsname.h presence... no
checking for sys/utsname.h... no
checking sys/wait.h usability... no
checking sys/wait.h presence... no
checking for sys/wait.h... no
checking bsd/libutil.h usability... no
checking bsd/libutil.h presence... no
checking for bsd/libutil.h... no
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking pty.h usability... no
checking pty.h presence... no
checking for pty.h... no
checking utmp.h usability... no
checking utmp.h presence... no
checking for utmp.h... no
checking termios.h usability... no
checking termios.h presence... no
checking for termios.h... no
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for unistd.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking for getgrgid_r... no
checking for getgrnam_r... no
checking for getpwnam_r... no
checking for getpwuid_r... no
checking for getpwnam... no
checking for getpwuid... no
checking for getpwent... no
checking for getgrent... no
checking for lchown... no
checking for setenv... no
checking for sysconf... no
checking for unsetenv... no
checking for clearenv... no
checking for nanosleep... no
checking for ptsname... no
checking for setitimer... no
checking for readdir_r... no
checking for telldir... yes
checking for seekdir... yes
checking for execvpe... yes
checking for struct stat.st_atim... no
checking for struct stat.st_mtim... no
checking for struct stat.st_ctim... no
checking for struct stat.st_atimespec... no
checking for struct stat.st_mtimespec... no
checking for struct stat.st_ctimespec... no
checking for struct stat.st_atimensec... no
checking for struct stat.st_mtimensec... no
checking for struct stat.st_ctimensec... no
checking for struct stat.st_atime_n... no
checking for struct stat.st_mtime_n... no
checking for struct stat.st_ctime_n... no
checking for struct stat.st_uatime... no
checking for struct stat.st_umtime... no
checking for struct stat.st_uctime... no
checking for struct passwd.pw_gecos... no
checking for utimensat... no
checking for futimens... no
checking for lutimes... no
checking for futimes... no
checking for mkstemps... no
checking for mkdtemp... no
checking for fsync... no
checking for fdatasync... no
checking for posix_fadvise... no
checking for posix_fallocate... no
checking for library containing shm_open... no
checking value of SIGABRT... 22
checking value of SIGALRM... -1
checking value of SIGBUS... -1
checking value of SIGCHLD... -1
checking value of SIGCONT... -1
checking value of SIGFPE... 8
checking value of SIGHUP... -1
checking value of SIGILL... 4
checking value of SIGINT... 2
checking value of SIGKILL... -1
checking value of SIGPIPE... -1
checking value of SIGQUIT... -1
checking value of SIGSEGV... 11
checking value of SIGSTOP... -1
checking value of SIGTERM... 15
checking value of SIGTSTP... -1
checking value of SIGTTIN... -1
checking value of SIGTTOU... -1
checking value of SIGUSR1... -1
checking value of SIGUSR2... -1
checking value of SIGPOLL... -1
checking value of SIGPROF... -1
checking value of SIGSYS... -1
checking value of SIGTRAP... -1
checking value of SIGURG... -1
checking value of SIGVTALRM... -1
checking value of SIGXCPU... -1
checking value of SIGXFSZ... -1
checking value of SIG_BLOCK... -1
checking value of SIG_SETMASK... -1
checking value of SIG_UNBLOCK... -1
checking value of SIGINFO... -1
checking value of SIGWINCH... -1
checking for _SC_GETGR_R_SIZE_MAX... no
checking for _SC_GETPW_R_SIZE_MAX... no
checking return type of usleep... int
checking return type of unsetenv... int
checking for RTLD_NEXT from dlfcn.h... no
checking for RTLD_DEFAULT from dlfcn.h... no
checking for openpty... no
checking for openpty in -lutil... no
checking for openpty in -lbsd... no
checking for /dev/ptmx... yes
checking for /dev/ptc... no
checking for library containing dlopen... no
checking build system type... i686-pc-msys
checking host system type... i686-pc-msys
checking target system type... i686-pc-msys
checking for library containing sem_close... no
configure: Not found
configure: creating ./config.status
config.status: creating unix.buildinfo
config.status: creating include/HsUnixConfig.h
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
Setup.hs: Package unix-2.7.1.0 can't be built on this system.


Reply to this email directly or view it on GitHub
#399 (comment)
.

@3noch
Member
3noch commented Jul 3, 2015

Just to prevent confusion, this is still not quite right. Somewhere in the build process stack still gets confused, probably because the fake OS is not entirely understood by the system as it should be. More details are in #495.

@mwu-tow
Contributor
mwu-tow commented Aug 26, 2015

There's one question that's puzzling me. Does anyone know why on Windows all dependencies are statically linked into the final executable?

On Linux there is no issue, because dependencies are dynamically loaded shared libraries. It has also several other advantages, like smaller file size, possibility of linking with multiple Haskell shared libraries (on Windows it would cause errors due to duplicated symbol definitions) and so on.

I checked the relevant documentation page for GHC and it was changed between GHC 7.0.3 and 7.0.4. In 7.0.3 it said

In principle you can use -shared without -dynamic in the link step. That means to statically link the rts all the base libraries into your new shared library. This would make a very big, but standalone shared library. Indeed this is exactly what we must currently do on Windows where -dynamic is not yet supported.

The documention from 7.0.4 removed all mentions of -dynamic not being supported on Windows. So I'd guess it was fixed.

So I wonder why it is still not used? Wouldn't compiling the packages with -dynamic on Windows solve the issue discussed here? Are there any known reasons or it was simply "no one tried to switch the flag" for Windows GHC builds?

@3noch
Member
3noch commented Aug 26, 2015

On Windows, even if you use a DLL to get libgmp, it's highly likely that you will also be the one conveying this DLL to the end user (via some installer, etc). According to the license, that case is considered equal with conveying an executable that statically links with libgmp. The only way to avoid this problem entirely is to use some third-party system to convey libgmp, as you cannot do it yourself. I suppose that on Linux this is accomplished via the package manager. On Windows, it's rare that you have this luxury. Of course, for those who are in a scenario where this limitation is not too onerous, then there are solutions that would help. For many (like myself), however, we cannot expect the end user to install any third-party tooling, etc. as part of our installation process.

@tejon
Contributor
tejon commented Aug 26, 2015

it's highly likely that you will also be the one conveying this DLL to the end user (via some installer, etc). According to the license, that case is considered equal with conveying an executable that statically links with libgmp.

That's not at all how I read section 4 of the LGPL, and (brief) Googling doesn't turn up anything that supports your interpretation. Do you have a source?

@Jookia
Jookia commented Aug 26, 2015

The GPLv3 and LGPLv3 don't explicitly state anything about static or dynamic linking, and in either case the most you have to provide is instructions on how to replace the library - you don't need to ship third party tooling. Here's a good link explaining how to comply: https://copyleft.org/guide/comprehensive-gpl-guidech12.html#x15-11100011.5

@3noch
Member
3noch commented Aug 26, 2015

@tejon

If you distribute the library along with your program, or are the separate distributor of the work in another context or as another product, you must distribute its corresponding source under the terms of LGPLv3 or GPLv3-or-later.

From here.

@Jookia
Jookia commented Aug 26, 2015

That's not equal as there's clearly two different cases. Even so, that doesn't say you have to do more than give installation instructions and library source code and why that's a problem.

@3noch
Member
3noch commented Aug 26, 2015

The first case essentially ends with "this falls under the second case," so I consider them to have equal LGPL implications. My point is merely that some software distributions can't easily rely on some third-party distribution system to convey the LGPL'ed library. In my case, the end user barely knows how to use a computer in the first place!

@Jookia
Jookia commented Aug 27, 2015

You don't need a third party distribution to convey the LGPLed library - just package source and installation information with your software. What's the problem?

@3noch
Member
3noch commented Aug 27, 2015

That's complying with the requirements of the LGPL and the reason this thread exists...no?

@Jookia
Jookia commented Aug 27, 2015

From what I can gather this thread exists to work on allowing removal of an LGPLed library rather than focusing on compliance given people don't want to bother complying. That's okay but I'm just trying to clarify what compliance actually is.

I was responding to you writing "For many (like myself), however, we cannot expect the end user to install any third-party tooling, etc. as part of our installation process." which didn't make much sense at all and seemed to be an incorrect assessment of what it takes to comply, so hopefully with clarification you can comply - I thought this might help in solving the issue you were having.

@tejon
Contributor
tejon commented Aug 27, 2015

@3noch: Ahh, I think you're tripping over commas. The pronoun matches the object, and the object is not your program:

If you distribute the library along with your program, [...] you must distribute its corresponding source

@3noch
Member
3noch commented Aug 27, 2015

@tejon I hope you're right. Can anyone confirm?

@3noch
Member
3noch commented Aug 27, 2015

@tejon I think I'm beginning to see it from your perspective. If that's the case, then this could be really good news for folks like me, except for the points brought up by @mwu-tow and @ezyang.

@Jookia
Jookia commented Aug 27, 2015

The section says this:

  1. Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

I think this is clear that that's the case.

@snoyberg
Contributor
snoyberg commented Sep 8, 2015

Given the work on alternative bindists, should this be closed?

@rvion
Contributor
rvion commented Sep 8, 2015

would ghc-musl make a better bindist default ?

@snoyberg
Contributor
snoyberg commented Sep 8, 2015

I don't think so:

  • It's much less tested than standard GHC
  • I don't think it works at all on Windows
  • Static linking would just make the specific problem being discussed (LGPL libraries being linked in) even worse
@rvion
Contributor
rvion commented Sep 8, 2015

Thanks for those infos
(not sure about the 3rd point: musl seems to be able to dynamic link anything just fine)

@snoyberg
Contributor

No objection given to my question about closing.

@snoyberg snoyberg closed this Sep 21, 2015
@varosi
varosi commented Jun 22, 2016 edited

stack build --os windowsintegersimple

Did not find .cabal file for stack-1.1.2 with Git SHA of 78d31fa4367593f8408ac142d2c3b40da54c247b
Right Nothing
Did not find .cabal file for opaleye-0.4.2.0 with Git SHA of bd719541cfb6d6eefe00172d228bb3331c73704b
Right Nothing
Did not find .cabal file for irc-dcc-1.2.1 with Git SHA of 34ed39699e28cadbdcec2601622b39198dbffabc
Right Nothing
No compiler found, expected minor version match with ghc-7.10.3 (x86_64) (based on resolver setting in ...\stack.yaml).
Try running "stack setup" to install the correct GHC into C:\stack\programs\x86_64-windowsintegersimple\

stack setup --os windowsintegersimple
I don't know how to install GHC for (OtherOS "windowsintegersimple",X86_64), please install manually

How it should be used with stack 1.1.2?

@borsboom
Contributor

@varosi: Don't have a Windows box available right now to try it, but it should be

stack setup --ghc-variant=integersimple
@varosi
varosi commented Jun 22, 2016

@borsboom, I have got this:

Downloaded lts-6.4 build plan.
Fetching package index ...remote: Counting objects: 1590, done.
remote: Compressing objects: 100% (1192/1192), done.
rRemote: Total 1590 (delta 403), reused 1427 (delta 365), pack-reused 0
Receiving objects: 100% (1590/1590), 500.58 KiB | 330.00 KiB/s, done.
Resolving deltas: 100% (403/403), completed with 199 local objects.
From https://github.com/commercialhaskell/all-cabal-hashes

  • [tag update] current-hackage -> current-hackage
    Fetched package index.
    Populated index cache.
    No information found for ghc-7.10.3.
    Supported versions for OS key 'windows64-integersimple': GhcVersion 7.8.4, GhcVersion 7.10.1, GhcVersion 7.10.2
@borsboom
Contributor

Looks like @kantp provided the past integer-simple bindists, but we have not received any yet for GHC 7.10.3 or GHC 8.0.1.

@3noch
Member
3noch commented Jun 22, 2016

I provided the bindists for 7.10.2, but unfortunately I no longer work with Windows and don't have access to my build machines.

@borsboom
Contributor
borsboom commented Jun 22, 2016 edited

@3noch: Ah sorry, I missed that in reading the history of this issue. Do you happen to have the process to create them documented anywhere?

In any case, we'll be happy to add the metadata for 7.10.3 and 8.0.1 windows-integersimple bindists when we're provided with them (and, you can always add setup-info to your own config for custom bindists).

@3noch
Member
3noch commented Jun 22, 2016

@borsboom: I followed the instructions on the GHC wiki (https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows) without too much trouble. Changing out the configuration to use integer-simple is not hard, but I don't recall the details. Hopping on to the GHC devs mailing list (I think they have an IRC channel too IIRC). For 32-bit bindists I literally fired up a 32-bit Windows VM, but that might be unnecessary.

@leohaskell
leohaskell commented Oct 12, 2016 edited

@borsboom , I'd like to provide a 7.10.3 windows-integersimple bindist if possible. Are there any special settings for the other bindists used by stack? BuildFlavor, etc..

@leohaskell
leohaskell commented Oct 14, 2016 edited

Here is an integersimple bindist built with the default build options. Please notify me if something else needs to be done.

@borsboom
Contributor

@leohaskell: did you test this bindist with stack setup? You can do so using stack setup --stack-setup-yaml <<<PATH>>> (with the <<<PATH>>> pointing to a modified version of stack-setup-2.yaml that adds your new bindist? If so, I'll put it somewhere official and add it to the normal stack-setup-2.yaml.

@leohaskell

The following is working:

stack setup --stack-setup-yaml <path-to-modified-setup.yaml> --ghc-variant=integersimple
@leohaskell

@borsboom, it's still not official?

@leohaskell

@borsboom, here is a ghc-8.0.1 integersimple bindist (tested with stack setup).

@PierreVDL

With stack [[Version 1.3.0, Git revision 99b910d x86_64 hpack-0.15.0]]
I get when typing

stack setup --stack-setup-yaml stack.yaml --ghc-variant=integersimple

Warning: stack.yaml: Unrecognized fields in SetupInfo: extra-deps, extra-package-dbs, flags,
 packages, resolver
Unable to find installation URLs for OS key: windows64-integersimple

What am I doing wrong?

@snoyberg
Contributor

I don't think you want to have the --stack-setup-yaml argument, especially if it's pointed to your project's stack.yaml file.

@quyse
Contributor
quyse commented Jan 23, 2017 edited

I have a problem with CI builds on Windows. As I need to set flags for certain packages to allow them to build with integersimple (text, hashable, cryptonite, etc...), these packages and all packages transitively depending on them automatically become extra-deps, and compiled binaries end up in .stack-work directory. Now the problem is that .stack-work got removed (intentionally) before every CI build, for build to be certainly clean, so all those packages got rebuilt every time, and it takes forever.

Normally (without integersimple) packages from stackage go into snapshot directories and not cleaned up, so builds on Linux are fast. I've seen the "extensible snapshot" feature which should allow me to make a derived snapshot with changed flags, so all those packages will go to snapshot directory, and therefore won't be rebuilt every time. Unfortunately last time I tried that feature it didn't support setting ghc-variant for a custom snapshot. Could such a setting be added please? Or maybe I'm missing something obvious and there is other way?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment