Linking only some libraries dynamically
Hi! When you have to link an specific library dynamically, then all libraries, as well as all parts of the program must be compiled and linked dynamically. Is this correct? Is it possible to link only one library dynamically and the rest statically? Regards, Volker signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: "... causes overflow in R_X86_... relocation"
Am Samstag, den 17.10.2020, 15:20 +0200 schrieb David Kraeutmann: > Relocation is part of the linking process. Specifically, external > function calls must be given a real run-time address instead of some > placeholder. > > R_X86_64_32 is a particular type of relocation, where the relocation > address is a 32-bit field. I understand now. > I believe this might be caused by Qtah being built without -fPIC. This is managed by Cabal. I see no easy way to rebuild it with -fPIC. Cloning the sources from Gitlab and doing the full build would probably be overkill. I've mailed Bryan Gardiner, the author of Qtah with a brief description of what is wrong. I'll do a full bug report, when requested. Maybe I'll switch to WxHaskell. Cheers, Volker signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
"... causes overflow in R_X86_... relocation"
Hi. I have a litte program named "svumb", which compiles and links without error or warning message. But when I start it, this happens: build/svumb: Symbol `qtahzmqt5zm0zi7zi0zm4ATcbzzMngNWCbnemaqWUdM_GraphicsziUIziQtahziGeneratedziWidgetsziQMessageBox_setText_closure' causes overflow in R_X86_64_32 relocation (... long list of similar messages ...) build/svumb: Symbol `stg_INTLIKE_closure' causes overflow in R_X86_64_32 relocation build/svumb: error while loading shared libraries: unexpected reloc type 0x0b Do those messages make sense to anyone? What is a "R_X86_64_32 relocation"? What is a "reloc type"? What's happening?? Calling "sudo ldconfig" doesn't help. The program uses the Qtah package, which is a Qt binding for Haskell. It might have something to do with this. It can't be linked statically, because then the following error occurs after starting the compiled and linked program: .../build/svumb: error while loading shared libraries: libqtah.so.0: cannot open shared object file: No such file or directory Compiling it dynamically had worked, but now I have the problem above. Regards, Volker signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Linking completely statically
Hi Thank you very much to Brandon, Tyson, Bardur, Thomas, Andreas, Aycan for your explanations. I thought that it probably was just another GHC argument or something like that. But it sounds quite complicated. What I have in mind isn't worth the trouble. I just wanted to have a statically linked version for inclusion in my backup and in my maintenance USB stick. Perhaps someone with insight could compile the answers to my post into a page for the Haskell Wiki. When I should really need it, I'll come back to this thread later. Cheers, Volker signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Linking completely statically
Am Dienstag, den 11.08.2020, 10:26 +0200 schrieb Herrmann, Andreas: > Hi Volker, Hi! > > Is it possible to link the remaining libraries statically too? > > Yes, it is possible to generate fully statically linked Haskell > binaries. Though it requires a bit of setup. For example the GNU C > library glibc is not really intended for fully static linking, but > you can use musl as an alternative libc instead. > > Probably the easiest way is to use static-haskell-nix [1]. Usage > instructions are available in the project README. See [2] if you're > not familiar with Nix. This looks complicated, even though it is the easiest way. I've tried to build it from the git sources, as well as from the latest release, but that failed. I'd have to look into nix, which is new to me. Be it as it may, it isn't that important for me right now. But thank you very much for your tips. Maybe I'll be going back to them later. Cheers, Volker > Recently, the Haskell extension to Bazel, rules_haskell, also gained > the ability to generate fully statically linked binaries building on > top of Nix, see [3]. > > Best, Andreas > > [1]: https://github.com/nh2/static-haskell-nix > [2]: https://nixos.org/ > [3]: > https://rules-haskell.readthedocs.io/en/latest/haskell-use-cases.html#building-fully-statically-linked-binaries signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Linking completely statically
Am Montag, den 10.08.2020, 09:11 +0200 schrieb Bardur Arantsson: > On 09/08/2020 14.50, Volker Wysk wrote: > > Hi! > > > > I know of the command line argument "-static". But this only > > affects > > the Haskell libraries. I want to link some programs completely > > statically, no external libraries needed. > > > > When just linking with "-static" I still have those dynamically > > linked > > things: > > > > desktop ~/bin $ ldd sicherung > > linux-vdso.so.1 (0x7ffdab53f000) > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 > > (0x7f3633da) > [--snip--] > > libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 > > (0x7f3633ce3000) > > libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 > > (0x7f3633cd7000) > > libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 > > (0x7f3633ccb000) > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > > (0x7f3633ad9000) > > /lib64/ld-linux-x86-64.so.2 (0x7f3633f0c000) > > > > > > Is it possible to link the remaining libraries statically too? > > > > As Brandon already mentioned, linking glibc statically is not really > supported (by glibc!), but what you can do is bundle a few of the > .so's > together with your binary and use RPATH to help your executable find > them at load time (well, dynamic link time). > > A project of ours where we do this is using Stack, so I can only > really > provide info on doing it with Stack, but hopefully you can adapt to > whatever you're using: > > We added > > ld-options: > - -Wl,-rpath,$ORIGIN/../lib > > to the 'executable' portion of the package.yaml. This instructs the > dynamic loader to look for libraries in '../lib' relative to the > executable's location. You can pick whatever path you want there. > > Once you have that bit set up, you can copy *most* of the libraries > .so's you're using to that folder on the install target and they'll > be > loaded from there. (Copying libc.so is ill advised, but most of the > others will work just fine. I believe ld-linux-... is also never ever > loaded from there since that *is* the dynamic loader.) > > (Of course a possibly more robust version of this is to just bundle > everything into a container of some sort, but that may be a bit > excessive for your needs.) Thank you for your elaborate explanation. This would be overkill for what I have in mind. I'm just trying to save a statically linked copy of a program of mine, which is involved in my backup, along with the backup, and also on a maintenance USB stick. I've stowed you answer away in my personal wiki, and may get back to it later. Regards, Volker signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Linking completely statically
Am Sonntag, den 09.08.2020, 09:53 -0400 schrieb Brandon Allbery:
> If you are obeying all the necessary restrictions on glibc, or you
> are
> using a different libc such as musl which is designed for static
> linking, then "-Wl,-static" should be sufficient. Doing this with
> glibc will likely result in a crash unless the same version of glibc
> is available at runtime.
Thanks for the tip! But I'll let it be for now.
Cheers,
Volker
>
> On 8/9/20, Volker Wysk wrote:
> > Am Sonntag, den 09.08.2020, 08:59 -0400 schrieb Brandon Allbery:
> > > Linux is not friendly to static linking, and you would need to
> > > either
> > > package or match exact versions of things like the nss and locale
> > > libraries that are dynamically loaded at runtime and don't show
> > > up in
> > > ldd. This limitation comes from glibc and is documented in its
> > > manual.
> >
> > That's bad. But, like you said, it *is* possible. The dar (disk
> > archiver) program comes with a statically linked version
> > "dar_static":
> >
> > % ldd dar_static
> > Das Programm ist nicht dynamisch gelinkt
> >
> > ("The program isn't linked dynamically.")
> >
> > From your answer, I assume that this isn't supported by GHC.
> >
> > Cheers
> > Volker
> >
> >
> > > On Sun, Aug 9, 2020, 08:50 Volker Wysk
> > > wrote:
> > > > Hi!
> > > >
> > > > I know of the command line argument "-static". But this only
> > > > affects
> > > > the Haskell libraries. I want to link some programs completely
> > > > statically, no external libraries needed.
> > > >
> > > > When just linking with "-static" I still have those dynamically
> > > > linked
> > > > things:
> > > >
> > > > desktop ~/bin $ ldd sicherung
> > > > linux-vdso.so.1 (0x7ffdab53f000)
> > > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> > > > (0x7f3633da)
> > > > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> > > > (0x7f3633d95000)
> > > > libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
> > > > (0x7f3633d9)
> > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> > > > (0x7f3633d8a000)
> > > > libpthread.so.0 => /lib/x86_64-linux-
> > > > gnu/libpthread.so.0
> > > > (0x7f3633d67000)
> > > > libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10
> > > > (0x7f3633ce3000)
> > > > libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1
> > > > (0x7f3633cd7000)
> > > > libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7
> > > > (0x7f3633ccb000)
> > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> > > > (0x7f3633ad9000)
> > > > /lib64/ld-linux-x86-64.so.2 (0x7f3633f0c000)
> > > >
> > > >
> > > > Is it possible to link the remaining libraries statically too?
> > > >
> > > > Regards,
> > > > Volker
> > > > ___
> > > > Glasgow-haskell-users mailing list
> > > > Glasgow-haskell-users@haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Linking completely statically
Am Sonntag, den 09.08.2020, 08:59 -0400 schrieb Brandon Allbery:
> Linux is not friendly to static linking, and you would need to either
> package or match exact versions of things like the nss and locale
> libraries that are dynamically loaded at runtime and don't show up in
> ldd. This limitation comes from glibc and is documented in its
> manual.
That's bad. But, like you said, it *is* possible. The dar (disk
archiver) program comes with a statically linked version "dar_static":
% ldd dar_static
Das Programm ist nicht dynamisch gelinkt
("The program isn't linked dynamically.")
From your answer, I assume that this isn't supported by GHC.
Cheers
Volker
>
> On Sun, Aug 9, 2020, 08:50 Volker Wysk wrote:
> > Hi!
> >
> > I know of the command line argument "-static". But this only
> > affects
> > the Haskell libraries. I want to link some programs completely
> > statically, no external libraries needed.
> >
> > When just linking with "-static" I still have those dynamically
> > linked
> > things:
> >
> > desktop ~/bin $ ldd sicherung
> > linux-vdso.so.1 (0x7ffdab53f000)
> > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> > (0x7f3633da)
> > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> > (0x7f3633d95000)
> > libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
> > (0x7f3633d9)
> > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> > (0x7f3633d8a000)
> > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x7f3633d67000)
> > libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10
> > (0x7f3633ce3000)
> > libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1
> > (0x7f3633cd7000)
> > libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7
> > (0x7f3633ccb000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> > (0x7f3633ad9000)
> > /lib64/ld-linux-x86-64.so.2 (0x7f3633f0c000)
> >
> >
> > Is it possible to link the remaining libraries statically too?
> >
> > Regards,
> > Volker
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Linking completely statically
Hi! I know of the command line argument "-static". But this only affects the Haskell libraries. I want to link some programs completely statically, no external libraries needed. When just linking with "-static" I still have those dynamically linked things: desktop ~/bin $ ldd sicherung linux-vdso.so.1 (0x7ffdab53f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3633da) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f3633d95000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f3633d9) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3633d8a000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3633d67000) libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x7f3633ce3000) libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x7f3633cd7000) libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x7f3633ccb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3633ad9000) /lib64/ld-linux-x86-64.so.2 (0x7f3633f0c000) Is it possible to link the remaining libraries statically too? Regards, Volker signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Linker trouble - position independent code(??)
Hi! I've found out how to do it: Use an explicit make rule: build/% : ghc -o $@ $^ -package hsshellscript But I have no idea why it stopped working... Happy Hacking, V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Linker trouble - position independent code(??)
Hi! All of a sudden, I can't link my programs any longer. This affects all my programs, which I build with a shared Makefile. But I haven't changed the Makefile... I get messages like this (indentation by me): cc build/sicherung.o build/Hsskripte.o build/Sicherung.o build/SicherungAktionen.o build/Text.o build/Wahl.o build/Zeit.o build/hssk.o -o build/sicherung /usr/bin/ld: build/sicherung.o: relocation R_X86_64_32S against undefined symbol `stg_upd_frame_info' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: build/Hsskripte.o: relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC ... more like this ... /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function `_start': (.text+0x20): undefined reference to `main' /usr/bin/ld: final link failed: Invalid operation collect2: error: ld returned 1 exit status I've attached the complete build messages. I've never dealt with position independent code. I've tried that "- fPIC" switch, but this produces lots of new error messages. Any idea of what's wrong? Bye, V.W. -*- mode: compilation; default-directory: "~/src/hsskripte/" -*- Compilation started at Thu Sep 26 03:33:34 LANG=C make -k build/sicherung ghc -o build/Hsskripte.o -c -ibuild -I. -isrc -XUndecidableInstances -fno-warn-deprecations -XScopedTypeVariables -XDeriveDataTypeable -XTypeSynonymInstances -XFlexibleInstances -XStandaloneDeriving -package regex-compat -package edit-distance -fno-warn-typed-holes -package containers -package pretty -package hsshellscript -package text -package bytestring -package time -package rfc5051 -static -odir build -hidir build src/Hsskripte.hs ghc -o build/Zeit.o -c -ibuild -I. -isrc -XUndecidableInstances -fno-warn-deprecations -XScopedTypeVariables -XDeriveDataTypeable -XTypeSynonymInstances -XFlexibleInstances -XStandaloneDeriving -package regex-compat -package edit-distance -fno-warn-typed-holes -package containers -package pretty -package hsshellscript -package text -package bytestring -package time -package rfc5051 -static -odir build -hidir build src/Zeit.hs ghc -o build/Sicherung.o -c -ibuild -I. -isrc -XUndecidableInstances -fno-warn-deprecations -XScopedTypeVariables -XDeriveDataTypeable -XTypeSynonymInstances -XFlexibleInstances -XStandaloneDeriving -package regex-compat -package edit-distance -fno-warn-typed-holes -package containers -package pretty -package hsshellscript -package text -package bytestring -package time -package rfc5051 -static -odir build -hidir build src/Sicherung.hs ghc -o build/Text.o -c -ibuild -I. -isrc -XUndecidableInstances -fno-warn-deprecations -XScopedTypeVariables -XDeriveDataTypeable -XTypeSynonymInstances -XFlexibleInstances -XStandaloneDeriving -package regex-compat -package edit-distance -fno-warn-typed-holes -package containers -package pretty -package hsshellscript -package text -package bytestring -package time -package rfc5051 -static -odir build -hidir build src/Text.hs ghc -o build/Wahl.o -c -ibuild -I. -isrc -XUndecidableInstances -fno-warn-deprecations -XScopedTypeVariables -XDeriveDataTypeable -XTypeSynonymInstances -XFlexibleInstances -XStandaloneDeriving -package regex-compat -package edit-distance -fno-warn-typed-holes -package containers -package pretty -package hsshellscript -package text -package bytestring -package time -package rfc5051 -static -odir build -hidir build src/Wahl.hs ghc -o build/SicherungAktionen.o -c -ibuild -I. -isrc -XUndecidableInstances -fno-warn-deprecations -XScopedTypeVariables -XDeriveDataTypeable -XTypeSynonymInstances -XFlexibleInstances -XStandaloneDeriving -package regex-compat -package edit-distance -fno-warn-typed-holes -package containers -package pretty -package hsshellscript -package text -package bytestring -package time -package rfc5051 -static -odir build -hidir build src/SicherungAktionen.hs ghc -o build/sicherung.o -c -ibuild -I. -isrc -XUndecidableInstances -fno-warn-deprecations -XScopedTypeVariables -XDeriveDataTypeable -XTypeSynonymInstances -XFlexibleInstances -XStandaloneDeriving -package regex-compat -package edit-distance -fno-warn-typed-holes -package containers -package pretty -package hsshellscript -package text -package bytestring -package time -package rfc5051 -static -odir build -hidir build src/sicherung.hs gcc -o build/hssk.o -c -O2 src/hssk.c -fPIC src/hssk.c:16:38: warning: 'struct statfs' declared inside parameter list will not be visible outside of this definition or declaration int statfs1(const char *path, struct statfs *buf) ^~ src/hssk.c: In function 'statfs1': src/hssk.c:24:9: warning: implicit declaration of function 'statfs'; did you mean 'statfs1'? [-Wimplicit-function-declaration] erg = statfs(path, buf); ^~ statfs1 cc build/sicherung.o build/Hsskripte.o build/Sicherung.o
Re: How to uninstall all cabal packages?
Again, thanks for the fast answer! Volker Am Sonntag, 3. Dezember 2017, 10:33:33 CET schrieb Thomas DuBuisson: > Packages registered with ghc are placed in the .ghc directory. You can > delete the directory entirely or selectively unregister using ghc-pkg. > > On Dec 3, 2017 10:31 AM, "Volker Wysk" <p...@volker-wysk.de> wrote: > > > Hi! > > > > I want to remove eveything which cabal has installed, and begin again with > > a clean installation. How is this accomplished? I've deleted ~/.cabal, but > > it still says that hsshellscript is already installed: > > > > desktop ~ $ cabal install hsshellscript > > Resolving dependencies... > > All the requested packages are already installed: > > hsshellscript-3.4.3 > > Use --reinstall if you want to reinstall anyway. > > > > Bye > > V.W. > > > > ___ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How to uninstall all cabal packages?
Yes, that's it. Thanks for the fast answer! Am Sonntag, 3. Dezember 2017, 20:32:20 CET schrieb Michael Snoyman: > You'll need to delete your ~/.ghc directory as well. > > On Sun, Dec 3, 2017 at 8:24 PM, Volker Wysk <p...@volker-wysk.de> wrote: > > > Hi! > > > > I want to remove eveything which cabal has installed, and begin again with > > a clean installation. How is this accomplished? I've deleted ~/.cabal, but > > it still says that hsshellscript is already installed: > > > > desktop ~ $ cabal install hsshellscript > > Resolving dependencies... > > All the requested packages are already installed: > > hsshellscript-3.4.3 > > Use --reinstall if you want to reinstall anyway. > > > > Bye > > V.W. > > > > ___ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
How to uninstall all cabal packages?
Hi! I want to remove eveything which cabal has installed, and begin again with a clean installation. How is this accomplished? I've deleted ~/.cabal, but it still says that hsshellscript is already installed: desktop ~ $ cabal install hsshellscript Resolving dependencies... All the requested packages are already installed: hsshellscript-3.4.3 Use --reinstall if you want to reinstall anyway. Bye V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: What happened to -optdep option?
Hello! Am Freitag, 6. Mai 2016, 00:35:01 CEST schrieb Bertram Felgenhauer: > Volker Wysk wrote: > > Hello! > > > > I'm using GHC 7.10.3 after an upgrade. I have the following in my > > Makefile: > > > > depend_mod :: lib/abh > > > > ghc -M $(CFLAGS_GHC_0) -dep-makefile -optdepbuild/depend.tmp -dep-suffix > > "p_" > You should drop the -optdep here > > > \ > > > >$(foreach m, $(MOD_HS) $(PROG_HS), src/$(m).hs) \ > >$(foreach m, $(MOD_CHS) $(PROG_CHS), build/$(m).hs) > > > > ... > > > > This used to work. The previous GHC version was 7.8. > > As a side effect of finally removing the -optdep-f flag, > > https://ghc.haskell.org/trac/ghc/ticket/2773 > (another relevant commit is 994d5e3cfc32cb624b63683205dd8fd876171d0c) > > the code that strips -optdep from the filename, which was required to > make -optdep-f -optdepfoo work, also got removed. The fact that > -dep-makefile continued to strip -optdep was an accident in my view. I've fixed it by removing "-optdepbuild/depend.tmp" and replacing "-dep- makefile" with "-dep-makefile build/depend.tmp". Thanks. Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
What happened to -optdep option?
Hello! I'm using GHC 7.10.3 after an upgrade. I have the following in my Makefile: depend_mod :: lib/abh ghc -M $(CFLAGS_GHC_0) -dep-makefile -optdepbuild/depend.tmp -dep-suffix "p_" \ $(foreach m, $(MOD_HS) $(PROG_HS), src/$(m).hs) \ $(foreach m, $(MOD_CHS) $(PROG_CHS), build/$(m).hs) ... This used to work. The previous GHC version was 7.8. Now GHC complains: -optdepbuild/depend.tmp: openBinaryFile: does not exist (No such file or directory) This looks like the -optdep argument isn't understood. There is no mention of it in the new/7.10.3 user manual. I don't know any longer what this "-optget" argument does, and it isn't in the documentation any longer. I googled the GHC web site. There it is mentioned that -optdep was deprecated, but almost all of the hits are very outdated (like ten years old). Can soneone tell me, how I should change my Makefile..? Greetings, Volker Wysk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How to remove a cabal package from the local system?
Am Donnerstag, 22. Januar 2015, 11:19:37 schrieb Albert Y. C. Lai: On 2015-01-21 10:36 AM, Volker Wysk wrote: I have installed/registered a new version of a package with cabal by accident. How can I remove it again? See my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove . In fact, read the whole thing. This describes what Evan is doing in his script. Bye Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to remove a cabal package from the local system?
Am Mittwoch, 21. Januar 2015, 19:39:50 schrieben Sie: On 2015-01-21 at 16:36:08 +0100, Volker Wysk wrote: I have installed/registered a new version of a package with cabal by accident. How can I remove it again? Not sure if this is what you want, but the `cab` tool has an `uninstall` sub-command to unregister and remove installed packages. [1]: http://hackage.haskell.org/package/cab Yes, this is what I want. But Evan's script works fine. I think I will stick to it. Greeting Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to remove a cabal package from the local system?
Hi! I have installed/registered a new version of a package with cabal by accident. How can I remove it again? There is something in ~/.cabal/packages/hackage.haskell.org, but the defective version isn't included. bye V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to remove a cabal package from the local system?
Am Mittwoch, 21. Januar 2015, 23:56:53 schrieben Sie: I use a shell script. It's really useful, surely there's some official way to do this? It looks like a remove command to cabal has been forgotten... This would be a feature request. I'm also missing a command to set the Default available version. Thanks for the script! Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Found hole
Am Mittwoch, 21. Januar 2015, 11:03:38 schrieben Sie: If there's any comments on how to improve the warning message to be less confusing I'd be interested to hear them. What about Found hole _foo with type: bar. This can also mean that _foo is not in scope. Bye V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Found hole
Am Mittwoch, 21. Januar 2015, 09:42:05 schrieben Sie: If such verbiage is added, it should probably read more like If you did not intend to insert a typed hole, _foo may have been misspelled. What about If you did not intend to insert a typed hole, _foo may have been misspelled or out of scope. In my case, it has been out of scope, but not misspelled. I think verbiage is a good thing in this case. Bye V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Found hole
Hello! What is a hole? This program fails to compile: main = _exit 0 I get this error message: ex.hs:1:8: Found hole ‘_exit’ with type: t Where: ‘t’ is a rigid type variable bound by the inferred type of main :: t at ex.hs:1:1 Relevant bindings include main :: t (bound at ex.hs:1:1) In the expression: _exit In an equation for ‘main’: main = _exit When I replace _exit with foo, it produces a not in scope error, as expected. What is special about _exit? It doesn't occur in the Haskell Hierarchical Libraries. Bye Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Package version question with Cabal
Am Montag, 19. Januar 2015, 23:32:09 schrieben Sie: On Mon, Jan 19, 2015 at 11:14 PM, Volker Wysk vertei...@volker-wysk.de wrote: I've uploaded my library to Hackage, and now I'm trying to install it via cabal: At a guess, the index has not yet been updated --- you may need to wait some time (might be as short as an hour) before trying to install it from Hackage. You also need to run cabal update to download the updated package index so your local cabal-install knows about the new package. I'm not completely sure what happened, but now it seems to work. The Default available version is the latest one. Looks like you have been right. Thanx. Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[solved] Re: Found hole
Hello! I've found what went wrong: _exit wasn't in scope, so it was interpreted to be a typed hole. Thanks Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Found hole
Hi!
Am Dienstag, 20. Januar 2015, 13:44:01 schrieben Sie:
The leading underscore invokes the typed holes extension. If you want to
use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line
of the source file.
I get this error, when I use {-# LANGUAGE NoTypedHoles #-}:
ex.hs:1:14: Unsupported extension: NoTypedHoles
I'm using GHC 7.8.3. Could it be that the NoTypedHoles extension was added
not before 7.8.4 (the most current version).
Bye
Volker
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Package version question with Cabal
Am Dienstag, 20. Januar 2015, 05:14:15 schrieb Volker Wysk: ~/src/hsshellscript $ cabal install Oops, this should be cabal install hsshellscript-3.3.3, not just cabal install: ~/src/hsshellscript $ cabal install hsshellscript-3.3.3 Resolving dependencies... All the requested packages are already installed: hsshellscript-3.3.3 Use --reinstall if you want to reinstall anyway. But when I try --reinstall, I get this error: ~/src/hsshellscript $ cabal --reinstall install hsshellscript-3.3.3 Resolving dependencies... cabal: Could not resolve dependencies: next goal: hsshellscript (user goal) rejecting: hsshellscript-3.3.2, 3.3.1, 3.3.0, 3.2.0, 3.1.0 (global constraint requires ==3.3.3) Dependency tree exhaustively searched. What does this mean...? I've also in vain searched for a way to remove a cabal installed package. Thanks, Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Package version question with Cabal
Hi! I've uploaded my library to Hackage, and now I'm trying to install it via cabal: ~/src/hsshellscript $ cabal install Resolving dependencies... In order, the following will be installed: hsshellscript-3.3.3 (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring hsshellscript-3.3.3... Building hsshellscript-3.3.3... Preprocessing library hsshellscript-3.3.3... In-place registering hsshellscript-3.3.3... Creating package registration file: /tmp/pkgConf-hsshellscript-3.37397.3 Installing library in /home/v/.cabal/lib/x86_64-linux-ghc-7.8.3/hsshellscript-3.3.3 Registering hsshellscript-3.3.3... Installed hsshellscript-3.3.3 ~/src/hsshellscript $ cabal list hsshellscript * hsshellscript Synopsis: Haskell for Unix shell scripting tasks Default available version: 3.3.2 Installed versions: 3.3.1, 3.3.2, 3.3.3 Homepage: http://www.volker-wysk.de/hsshellscript/ License: LGPL The thing wich looks like a problem is, that the new version isn't made the Default available version. It is 3.3.3, but Default available version is still 3.3.2. Is this a problem? How do I register a new default version? Bye Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Old code broken by new Typeable class
Hi!
I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my code,
because the Typeable class has been changed. The compiler produces this
message:
-
src/HsShellScript/ProcErr.chs:2294:4:
‘typeOf’ is not a (visible) method of class ‘Typeable’
-
I want to define System.Posix.Process.ProcessStatus to be an instance of
Typeable, so I can throw and catch it as an exception. ProcessStatus isn't
typeable by default.
Is it still possible to make ProcessStatus a member of Typeable? How?
Obviously, you can't accomplish it by deriving Typeable, because the definition
can't be changed any longer.
This is the spot in question:
--
import System.Posix.Process
import Data.Typeable
{-
data ProcessStatus = Exited ExitCode
/ | Terminated Signal/
/ | Stopped Signal/
deriving (Eq, Ord, Show)
-}
instance Typeable ProcessStatus where
typeOf = const tyCon_ProcessStatus
tyCon_ProcessStatus = mkTyConApp (mkTyCon3 hsshellscript
HsShellScript.ProcErr
Posix.ProcessStatus) []
instance Exception ProcessStatus
--
Thanks,
V.W.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Old code broken by new Typeable class
Am Dienstag, 5. August 2014, 12:49:29 schrieb Carter Schonwald: more concretely #if defined(__GLASGOW_HASKELL__) ( __GLASGOW_HASKELL__ = 707) --- do the deriving version here I can't do a deriving version, because ProcessStatus is part of the GHC libraries (System.Posix.Process). Its definition can't be changed. #else --- your current stuff #endif Cheers, V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Old code broken by new Typeable class
Am Dienstag, 5. August 2014, 12:46:23 schrieb Carter Schonwald: i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) in 7.8 you can't define userland typeable instances, you need only write deriving (Typeable) and you're all set. add some CPP to select the instances suitable So you need to be able to change the definition of the data type, in order to add deriving (Typeable). It's not possible to add a Typeable instance declaration later. When you can't change the definition, you're out of luck. Okay, V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Old code broken by new Typeable class
Am Dienstag, 5. August 2014, 13:59:26 schrieb Brandon Allbery: On Tue, Aug 5, 2014 at 1:47 PM, Volker Wysk vertei...@volker-wysk.de So you need to be able to change the definition of the data type, in order to add deriving (Typeable). It's not possible to add a Typeable instance declaration later. Are you sure? There is a standalone deriving syntax. deriving instance Typeable ProcessStatus Yes, that's the solution. You need these options for GHC: -XStandaloneDeriving -XDeriveDataTypeable Thanks, and Bye, V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to work around GHC bug
Hi! The following program demonstrates a (another) GHC bug. The command line isn't properly decoded to Unicode. arg.hs-- import System main = do [a] - getArgs putStrLn (show a) -- When called like this: ./arg ä The program will output this: \195\164 I'll report this as a bug in the GHC Trac. But for now, I need to work around the problem somehow. The encoders in GHC.IO.Encoding all work on buffers. How do I recode the command line, in order to get proper Unicode strings? Bye Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to work around GHC bug
Am Mittwoch 14 März 2012, 15:08:38 schrieben Sie: On 14 March 2012 13:51, Volker Wysk p...@volker-wysk.de wrote: import System main = do [a] - getArgs putStrLn (show a) a here is already of type String. If you don't call show on it, it'll do the expected thing. Try: main = do [a] - getArgs putStrLn a That's not true. The result is: ./tmp $ ./arg ä ä Bye Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to work around GHC bug
Am Mittwoch 14 März 2012, 16:04:25 schrieben Sie: I have $LANG = en_GB.UTF-8 and I am on mac os x, if that helps. Now we have the riddle, of why it works differently on your machine. However, e can leave it at that, I think. Happy hacking, Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to work around GHC bug
Am Mittwoch 14 März 2012, 16:19:33 schrieben Sie: Quoth Volker Wysk p...@volker-wysk.de, I'll report this as a bug in the GHC Trac. But for now, I need to work around the problem somehow. The encoders in GHC.IO.Encoding all work on buffers. How do I recode the command line, in order to get proper Unicode strings? Data.Text might work for you. I'm not guaranteeing that you'll get a proper Unicode string out of this, but you'll get a String with one (LATIN-1) value per character: import qualified Data.ByteString.Char8 as P import Data.Text.Encoding (decodeUtf8) import qualified Data.Text as T let arghs = [\195\164] let args = map (T.unpack . decodeUtf8 . P.pack) arghs Yes, this works! Thanks! Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bug with unicode characters in file names
Hi This is some file äöü.hs with three German umlauts in the file name: main = putStrLn äöü Now I want to get the dependendency information. Therefore I call: ghc -M äöü.hs The following gets added to the Makefile: # DO NOT DELETE: Beginning of Haskell dependencies äöü.o : äöü.hs # DO NOT DELETE: End of Haskell dependencies The umlauts get transformed from three UTF-8 encoded characters (six bytes) to six UTF-8 encoded characters (twelve bytes). I'm sending this to glasgow-haskell-users instead of glasgow-haskell-bugs, because the latter does not seem to accept my messages. I receive nothing, neither the message in the mailing list, nor any error message. Bye, V.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting the file descriptor of a handle, without closing it
Am Montag 12 März 2012, 12:31:27 schrieb Simon Marlow: On 11/03/2012 01:31, Volker Wysk wrote: However, I want to use it with stdin, stdout and stderr, only. Is there some reason you can't just use 0, 1, and 2? This is complicated. I want to be able to fork a child action, and communicate with it through stdin/stdout. I also want to be able to replace the child with an external program, and communicate with it through a stdout-stdin pipe. Something like this: subproc (outm Durch die Röhre -|- exec /bin/cat []) I don't rely on stdin/-out/-err still being open. One might be closed, and the file descriptor might be reallocated (for a subsequently opened file or whatever). I also don't rely on stdin being fd 0, stdout being fd 1, stderr being fd 2. If you really want to know what's going on, here is the documentation: http://volker-wysk.de/hsshellscript/apidoc/HsShellScript.html#v%3Aexecute_file These three should never be garbage collected, should they? I think it would be safe to use unsafeWithHandleFd this way. Am I right? I wouldn't do that, but you're probably right that it is safe right now. (but no guarantees that it will continue to work for ever.) So I need a fixed unsafeWithHandleFd, for it to work forever? I guess, I'll leave it as it is, for now. Cheers Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Getting the file descriptor of a handle, without closing it
Hello!
A few months ago, I started a discussion about how to extract the file
descriptor of a handle, without the side effect of closing the handle. Bas van
Dijk kindly provided the following function:
unsafeWithHandleFd :: Handle - (Fd - IO a) - IO a
(The action in the second argument is applied to the file descriptor of the
handle in the first argument.)
Now I'm trying to use it, but it appears to have a bug. This program shows it:
snip--
import IO
import GHC.IO.Handle.Types-- haType, haDevice
import GHC.IO.Handle.Internals-- withHandle', do_operation
import System.Posix.Types -- Fd
import System.IO.Error-- ioeSetErrorString
import Data.Typeable -- cast
import GHC.IO.Exception -- IllegalOperation
import GHC.IO.FD hiding (stdin, stdout, stderr) -- fdFD
import Foreign.C -- CInt
import Control.Concurrent.MVar (MVar)
main = do
-- Works okay
unsafeWithHandleFd stdin $ \fd -
putStrLn (stdin: fd = ++ show fd)
-- Blocks
unsafeWithHandleFd stdout $ \fd -
putStrLn (stdout: fd = ++ show fd)
-- By Bas van Dijk
unsafeWithHandleFd :: Handle - (Fd - IO a) - IO a
unsafeWithHandleFd h@(FileHandle _ m) f = unsafeWithHandleFd' h m f
unsafeWithHandleFd h@(DuplexHandle _ _ w) f = unsafeWithHandleFd' h w f
unsafeWithHandleFd' :: Handle - MVar Handle__ - (Fd - IO a) - IO a
unsafeWithHandleFd' h m f =
withHandle' unsafeWithHandleFd h m $ \h_@Handle__{haDevice} -
case cast haDevice of
Nothing - ioError (System.IO.Error.ioeSetErrorString
(System.IO.Error.mkIOError IllegalOperation
unsafeWithHandleFd (Just h) Nothing)
handle is not a file descriptor)
Just fd - do
x - f (Fd (GHC.IO.FD.fdFD fd))
return (h_, x)
snip--
The first call of unsafeWithHandleFd, works as expected. The second one blocks.
I need unsafeWithHandleFd, or something similar, in order to port my
HsShellScript library (http://volker-wysk.de/hsshellscript/index.html) to the
current version of GHC.
If someone who understands the internals of the GHC IO libraries, had a hint,
or even a fix, I'd be very grateful.
Sincerely,
Volker Wysk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting the file descriptor of a handle, without closing it
Hi This is an addition to my previous post. This modified version of main seems to work: main = do fd - unsafeWithHandleFd stdin return putStrLn (stdin: fd = ++ show fd) fd - unsafeWithHandleFd stdout return putStrLn (stdout: fd = ++ show fd) The way I understand it, unsafeWithHandleFd's job is to keep a reference to the hande, so it won't be garbage collected, while the action is still running. Garbage collecting the handle would close it, as well as the underlying file descriptor, while the latter is still in use by the action. This can't happen as long as use of the file descriptor is encapsulated in the action. This encapsulation can be circumvented by returning the file descriptor, and that's what the modified main function above does. This should usually never be done. However, I want to use it with stdin, stdout and stderr, only. These three should never be garbage collected, should they? I think it would be safe to use unsafeWithHandleFd this way. Am I right? unsafeWithHandleFd is still broken (see previous message), but for my purposes it wouldn't necessarily need to be fixed. Happy hacking Volker Wysk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Getting the file descriptor from a handle, without closing it
Hello!
I need to get the file descriptors of some handles, but the handles should not
be modified. They should not be closed by the operation.
I guess, that the handle gets closed for a reason. But I'm using the revealed
file descriptors in a way which should pose no problems for the integrity of
the GHC library.
In order to make a non-closing handleToFd function, I'm studying GHC's library
source code. But there's a lot which I can't make much sense, because it uses
non-standard language features (GHC extensions), which I'm not familiar with.
I don't mean you to explain these GHC extensions to me. I just want to give an
impression of the problems I encounter:
1.
data FD = FD {
fdFD :: {-# UNPACK #-} !CInt,
fdIsNonBlocking :: {-# UNPACK #-} !Int
}
What is that exclamation mark? And that {-# UNPACK #-}?
2.
handleToFd' :: Handle - Handle__ - IO (Handle__, Fd)
handleToFd' h h_@Handle__{haType=_,..} = do
case cast haDevice of
-- ...
haDevice should be a function. How could you cast it?
3.
data Handle__
= forall dev enc_state dec_state .
(IODevice dev, BufferedIO dev, Typeable dev) =
Handle__ {
-- ...
}
deriving Typeable
What's that forall thing?
4.
handleToFd' h h_@Handle__{haType=_,..} = do
case cast haDevice of
Nothing - -- ...
Just fd - do
-- ...
return (Handle__{haType=ClosedHandle,..},
Fd (fromIntegral (FD.fdFD fd)))
What's this .. inside Handle__{haType=ClosedHandle,..}?
If anyone can point out to me, how this non-blocking handleToFd function
should be made, I would be grateful.
Greetings
Volker Wysk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting the file descriptor from a handle, without closing it
On Saturday 01 October 2011 08:30:40 Volker Wysk wrote: If anyone can point out to me, how this non-blocking handleToFd function should be made, I would be grateful. This should be non-CLOSING handleToFd function. Sorry. Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
REQ: add a non-closing version of handleToFd
Hello
The function to extract a file descriptor from a handle, handleToFd, closes
the handle as a side effect. This appears to be necessary in the general
case, otherwise the implementers wouldn't have made it this way.
But there are cases in which it isn't necessary to close the handle.
For instance, this little function needs to extract the file descriptor, but
there is no need to close, or change, the handle.
isatty :: Handle-- ^ Handle to check
- IO Bool -- ^ Whether the handle is connected to a terminal
isatty h = do
fd - handleToFd_noclose h
isterm - {# call isatty as hssh_c_isatty #}-- this is c2hs
((fromIntegral fd) :: CInt)
return (isterm /= (0::CInt))
handleToFd_noclose :: Handle - IO Fd
-- to be implemented
The isatty above can't be implemented with things the way they are. To me,
this is a serious drawback.
The cases, in which the handle needs to be closed, should be identified, and
documented. Then, a version of handleToFd, which doesn't close the handle can
be implemented.
Cheers
Volker
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Mysterious function timer_settime
Hi! Im porting my HsShellScript library to GHC-7.0.4 and to Cabal/Hackage. It builds and installs fine: ~/src/hsshellscript-3.0.0 $ cabal clean cleaning... ~/src/hsshellscript-3.0.0 $ cabal configure Resolving dependencies... Configuring hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal build Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... (...) Registering hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal haddock Running Haddock for hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... (...) Documentation created: dist/doc/html/hsshellscript/index.html ~/src/hsshellscript-3.0.0 $ cabal install Resolving dependencies... Configuring hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... Registering hsshellscript-3.0.0... Installing library in /home/v/.cabal/lib/hsshellscript-3.0.0/ghc-7.0.4 Registering hsshellscript-3.0.0... I've made a fine little test program src/test.hs: import HsShellScript main = (outm 3\n1\n2\n) -|- exec /usr/bin/sort [-n] But this doesn't work. It generates a mysterious error message: ~/src/hsshellscript-3.0.0 $ src/test test: stderr: hPutStr: illegal operation (handle is closed) test: timer_settime: Invalid argument timer_settime occurs only in the generated test binary. It doesn't occur anywhere in the library or in /usr/bin/sort: ~/src/hsshellscript-3.0.0 $ find -type f -print0|xargs -0 egrep timer_settime Übereinstimmungen in Binärdatei ./src/test. ~/src/hsshellscript-3.0.0 $ egrep timer_settime /usr/bin/sort (no output) It looks like GHC has introduced this mysterous call of timer_settime. What does that mean? Thanks for any help, Volker W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mysterious function timer_settime
Hi Here's an addition to my Mysterious function timer_settime message: This test program: import HsShellScript main = call (exec /bin/echo [bla bla] -|- exec /bin/cat []) produces this output: test: test: stderr: hPutStr: illegal operation (handle is closed)stderr: hPutStr: illegal operation (handle is closed) test: timer_settimetest: : Invalid argument timer_settime: Invalid argument test: Exited (ExitFailure 1) I'm almost sure that the two examples work fine in the last working version of HsShellScript. They use GHC-6.11. (I can't verify this, since I have GHC-7.0.4 version installed. The old GHC version isn't available as a Debian package any longer.) So there appears to be a downwards-incompatibilty in the GHC libraries. I'm fiddling with the internals quite a bit, in order to get forks, pipes and redirects etc. working. Any hint would be appreciated. Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mysterious function timer_settime
On Wednesday 28 September 2011 14:27:13 Volker Wysk wrote: I'm almost sure that the two examples work fine in the last working version of HsShellScript. They use GHC-6.11. That is, they work fine when compiled with GHC-6.11. Sorry. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Cabal things
Hello I'm new to Cabal, and I'm trying to Cabalize my library HsShellScript, with help by Howard Golden. I'm using the Simple Build Infrastructure. 1. I'm irritated by the fact, that calling the Cabal with runhaskell configure; runhaskell build; runhaskell install is _not_ sufficent in many cases. You need additional arguments for runhaskell configure, and runhaskell build can't build everything, you need other actions in many cases. I need haddock, and it can't be specified in the .cabal file, or run by runhaskell build. I'm about to include this Makefile: -snip-- default :: build configure :: runhaskell Setup.lhs configure --ghc --prefix=/tmp build :: runhaskell Setup.lhs build runhaskell Setup.lhs haddock install :: runhaskell Setup.lhs install -snip-- This would make the installation a matter of make configure; make; make install. Is this the way it should be done? 2. I have some HTML pages of additional documentation, which need to be installed, and need to be included in the (sdist) generated distribution package. I have no clue how this should be done. Cheers, Volker___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
handleToFd without closing of the file descriptor
Hello I need to get the file descriptor, which is encapsulated inside a handle. handleToFd gets it, but the fd is closed. Is it possible to extract the fd from the handle, without modifying the handle? Greetings, Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
handleToFd without closing of the file descriptor
Hello I need to get the file descriptor, which is encapsulated inside a handle. handleToFd gets it, but the fd is closed. Is it possible to extract the fd from the handle, without modifying the handle? Greetings, Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to get the file descriptor of a handle?
Hello I'd like to know how you get the file descriptor, which is incapsulated in a handle. The libraries GHC.IO.Handle/GHC.IO.Handle.FD only provide for the other direction. The function haFD, which I've used before I've updated to the current version of GHC (6.12), appears to be in use two times in the libraries. But there isn't a definition anywhere. Any help would be appreciated. Cheers, Volker -- Volker Wysk p...@volker-wysk.de ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fw: Re: Re[2]: No more ExitException? - documentation bug
The following message went to Bulat Ziganshin alone. So here it is for the mailing list. Sorry. Begin forwarded message: On Wed, 27 Jan 2010 12:43:13 +0300 Bulat Ziganshin bulat.zigans...@gmail.com wrote: exitWith throws the ExitCode when it is called. This leads to the shutdown of the program, if it isn't caught. Just like ExitException. This isn't documented. i've googled for exitWith throws the ExitCode and it pointed me to the exitWith docs: Computation exitWith code throws ExitException code. This is the source code of exitWith: -snip- -- --- -- exitWith -- | Computation 'exitWith' @code@ throws 'ExitException' @c...@. -- Normally this terminates the program, returning @code@ to the -- program's caller. Before the program terminates, any open or -- semi-closed handles are first closed. -- -- A program that fails in any other way is treated as if it had -- called 'exitFailure'. -- A program that terminates successfully without calling 'exitWith' -- explicitly is treated as it it had called 'exitWith' 'ExitSuccess'. -- -- As an 'ExitException' is not an 'IOError', 'exitWith' bypasses -- the error handling in the 'IO' monad and cannot be intercepted by -- 'catch' from the Prelude. However it is an 'Exception', and can -- be caught using the functions of Control.Exception. This means -- that cleanup computations added with 'Control.Exception.bracket' -- (from Control.Exception) are also executed properly on 'exitWith'. #ifndef __NHC__ exitWith :: ExitCode - IO a exitWith ExitSuccess = throwIO ExitSuccess exitWith code@(ExitFailure n) | n /= 0 = throwIO code #ifdef __GLASGOW_HASKELL__ | otherwise = ioError (IOError Nothing InvalidArgument exitWith ExitFailure 0 Nothing) #endif #endif /* ! __NHC__ */ -snip- As you can see, it throws the ExitCode, not an ExitException. The documentation is faulty. Cheers, Volker -- Volker Wysk v...@volker-wysk.de -- Volker Wysk v...@volker-wysk.de ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: No more ExitException? - documentation bug
On Wed, 27 Jan 2010 03:48:47 +0100 Volker Wysk v...@volker-wysk.de wrote: I'm porting my HsShellScript library from GHC-6.8 to GHC-6.10. I'm catching an ExitException in the old version. The only occurence of ExitException in the GHC 6.10 libraries is in Control.OldException. So how is this done in GHC 6.10+ ? What replaces the old ExitException? I'm answering my own question: exitWith throws the ExitCode when it is called. This leads to the shutdown of the program, if it isn't caught. Just like ExitException. This isn't documented. Cheers, Volker -- Volker Wysk p...@volker-wysk.de ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linking problems after switching from GHC5 to GHC6
I can't link with a library any longer, after switching from ghc5 to
ghc6.2. I've recompiled the library with the new compiler version, so
that's not the problem.
[snip]
ghc -o build/test0 build/test0.o -odir build
`src/lib/hsunix-config --local --libs`
build/test0.o(.text+0x25): In function `__stginit_Main_':
: undefined reference to `__stginit_HsUnix_'
build/test0.o(.text+0xec): In function `Main_main_srt':
: undefined reference to `HsUnix_mainwrapper_closure'
build/test0.o(.text+0x151): In function `Main_main_entry':
: undefined reference to `HsUnix_mainwrapper_closure'
collect2: ld returned 1 exit status
make: *** [build/test0] Error 1
rm build/test0.o
Strange. Could you send us the output from -v?
Okay:
Glasgow Haskell Compiler, Version 6.2, for Haskell 98, compiled by GHC version 6.2
Using package config file: /usr/lib/ghc-6.2/package.conf
Packages
Package
{name = data,
auto = False,
import_dirs = [/usr/lib/ghc-6.2/hslibs-imports/data],
source_dirs = [],
library_dirs = [/usr/lib/ghc-6.2],
hs_libraries = [HSdata],
extra_libraries = [],
include_dirs = [],
c_includes = [],
package_deps = [haskell98, lang, util],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = lang,
auto = False,
import_dirs = [/usr/lib/ghc-6.2/hslibs-imports/lang],
source_dirs = [],
library_dirs = [/usr/lib/ghc-6.2],
hs_libraries = [HSlang],
extra_libraries = [HSlang_cbits],
include_dirs = [],
c_includes = [HsLang.h],
package_deps = [base],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = base,
auto = True,
import_dirs = [/usr/lib/ghc-6.2/imports],
source_dirs = [],
library_dirs = [/usr/lib/ghc-6.2],
hs_libraries = [HSbase],
extra_libraries = [HSbase_cbits],
include_dirs = [],
c_includes = [HsBase.h],
package_deps = [rts],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = rts,
auto = False,
import_dirs = [],
source_dirs = [],
library_dirs = [/usr/lib/ghc-6.2],
hs_libraries = [HSrts],
extra_libraries = [m, gmp, dl],
include_dirs = [/usr/lib/ghc-6.2/include],
c_includes = [Stg.h],
package_deps = [],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts =
[-u,
GHCziBase_Izh_static_info,
-u,
GHCziBase_Czh_static_info,
-u,
GHCziFloat_Fzh_static_info,
-u,
GHCziFloat_Dzh_static_info,
-u,
GHCziPtr_Ptr_static_info,
-u,
GHCziWord_Wzh_static_info,
-u,
GHCziInt_I8zh_static_info,
-u,
GHCziInt_I16zh_static_info,
-u,
GHCziInt_I32zh_static_info,
-u,
GHCziInt_I64zh_static_info,
-u,
GHCziWord_W8zh_static_info,
-u,
GHCziWord_W16zh_static_info,
-u,
GHCziWord_W32zh_static_info,
-u,
GHCziWord_W64zh_static_info,
-u,
GHCziStable_StablePtr_static_info,
-u,
GHCziBase_Izh_con_info,
-u,
GHCziBase_Czh_con_info,
-u,
GHCziFloat_Fzh_con_info,
-u,
GHCziFloat_Dzh_con_info,
-u,
GHCziPtr_Ptr_con_info,
-u,
GHCziPtr_FunPtr_con_info,
-u,
GHCziStable_StablePtr_con_info,
-u,
GHCziBase_False_closure,
-u,
GHCziBase_True_closure,
-u,
GHCziPack_unpackCString_closure,
-u,
GHCziIOBase_stackOverflow_closure,
-u,
GHCziIOBase_heapOverflow_closure,
-u,
GHCziIOBase_NonTermination_closure,
-u,
GHCziIOBase_BlockedOnDeadMVar_closure,
-u,
GHCziIOBase_Deadlock_closure,
-u,
GHCziWeak_runFinalizzerBatch_closure,
-u,
__stginit_Prelude],
framework_dirs = [],
extra_frameworks = []}
Package
{name = haskell98,
auto = True,
import_dirs = [/usr/lib/ghc-6.2/imports],
source_dirs = [],
library_dirs = [/usr/lib/ghc-6.2],
hs_libraries = [HShaskell98],
extra_libraries = [],
include_dirs = [],
c_includes = [],
package_deps = [base],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = haskell-src,
auto = True,
import_dirs = [/usr/lib/ghc-6.2/imports],
source_dirs = [],
library_dirs = [/usr/lib/ghc-6.2],
hs_libraries = [HShaskell-src],
extra_libraries = [],
include_dirs = [],
c_includes = [],
package_deps = [base, haskell98],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = network,
linking problems after switching from GHC5 to GHC6
Hello I can't link with a library any longer, after switching from ghc5 to ghc6.2. I've recompiled the library with the new compiler version, so that's not the problem. With GHC5: everything is fine: ~/src/hsunix $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.04.2 ~/src/hsunix $ make clean ... ~/src/hsunix $ make build/test0 ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixArgs.o src/lib/HsUnixArgs.hs ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixShell.o src/lib/HsUnixShell.hs ... ar cqs build/libhsunix.a build/HsUnixArgs.o build/HsUnix.o build/HsUnixMisc.o build/HsUnixPaths.o build/HsUnixShell.o build/HsUnixCommands.o build/HsUnixProcErr.o build/hsunix.o ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -ohi build/test0.hi -c -o build/test0.o src/test/test0.hs ghc -o build/test0 build/test0.o -odir build `src/lib/hsunix-config --local --libs` ~/src/hsunix $ src/lib/hsunix-config --local --libs build/libhsunix.a -syslib lang -syslib posix -syslib text -syslib util With GHC6, I get errors about undefined symbols. It are symbols which are defined in the library (libhsunix.a): ~/src/hsunix $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2 ~/src/hsunix $ make clean ... ~/src/hsunix $ make build/test0 ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixArgs.o src/lib/HsUnixArgs.hs ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixShell.o src/lib/HsUnixShell.hs ... ar cqs build/libhsunix.a build/HsUnixArgs.o build/HsUnix.o build/HsUnixMisc.o build/HsUnixPaths.o build/HsUnixShell.o build/HsUnixCommands.o build/HsUnixProcErr.o build/hsunix.o ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -ohi build/test0.hi -c -o build/test0.o src/test/test0.hs ghc -o build/test0 build/test0.o -odir build `src/lib/hsunix-config --local --libs` build/test0.o(.text+0x25): In function `__stginit_Main_': : undefined reference to `__stginit_HsUnix_' build/test0.o(.text+0xec): In function `Main_main_srt': : undefined reference to `HsUnix_mainwrapper_closure' build/test0.o(.text+0x151): In function `Main_main_entry': : undefined reference to `HsUnix_mainwrapper_closure' collect2: ld returned 1 exit status make: *** [build/test0] Error 1 rm build/test0.o Oddly, the problem does not occur when I directly pass the haskell source file to the compiler instead of the object file which is created from it: ~/src/hsunix $ ghc -o build/test0 src/test/test0.hs -odir build `src/lib/hsunix-config --local --libs` `src/lib/hsunix-config --local --cflags` ^ instead of build/test0.o which is created from it (succeeds) Does anyone have any idea of what's wrong? I find this especially strange, because it works with GHC5. Bye, V.W. -- Volker Wysk [EMAIL PROTECTED] http://www.volker-wysk.de ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
