Compiling HOpenGL under recent versions of GHC
Hi there, I just recently installed Gentoo Linux with the intention of using HOpenGL. Unfortunately I'm having problems compiling - something seems to use a "_casm_" directive (I think) and GHC complains that this isn't valid. So far as I can tell it was removed from the language a while ago. Anyway, is this an expected problem or have I misconfigured something? If this isn't a known problem I'll try again and carefully document what I do. Thanks. Regards, Weeble.
[ I've CC'd to Andres as his function(?) as the GHC Gentoo maintainer/packager. ] Weeble wrote:
I just recently installed Gentoo Linux with the intention of using HOpenGL. Unfortunately I'm having problems compiling - something seems to use a "_casm_" directive (I think) and GHC complains that this isn't valid. [...]
It looks like you're using one of the old versions (1.0x) of HOpenGL from http://haskell.org/HOpenGL, which are not supported anymore. The development takes place in the fptools CVS repository now, so GHC, Hugs and NHC can use it more easily. I don't know much about Gentoo Linux, but it looks like that there is a GHC 6.2.1 in dev-lang/ghc. This is almost what you want... :-) It already contains some basic OpenGL functionality, but being on a release branch, it doesn't have all the features of the CVS main branch (full OpenGL 1.5 support apart from NURBS, API docs at http://haskell.org/HOpenGL/newAPI/). So you are basically left with 2 options: * Wait for the official release of GHC 6.4, but this will probably take some time. * Build GHC from the CVS main branch or the nightly snapshots (available at http://www.haskell.org/ghc/dist/current/dist/). I've got no idea how to do this via the ebuild system, but perhaps Andres Loeh can help. He seems to be the maintainer/packager for GHC on Gentoo. If you can live without a properly packaged GHC version, simply doing things by hand is not that hard nowadays (given that you have sufficiently recent versions of Alex, Happy and Haddock installed): cd fptools (or whatever the toplevel directory is called) autoreconf ./configure --enable-hopengl make all make html make install make install-docs Depending on your needs, you might want to use the --prefix and/or --libdir options of configure. Building Hugs from CVS with OpenGL support is not that hard, either: cg hugs98 (or whatever the toplevel directory is called) make EXTRA_CONFIGURE_OPTS="--enable-hopengl" Well, I should really update my HOpenGL web pages... :-] Cheers, S.
[ I've CC'd to Andres as his function(?) as the GHC Gentoo maintainer/packager. ]
* Build GHC from the CVS main branch or the nightly snapshots (available at http://www.haskell.org/ghc/dist/current/dist/). I've got no idea how to do this via the ebuild system, but perhaps Andres Loeh can help. He seems to be the maintainer/packager for GHC on Gentoo.
I have a ghc-cvs ebuild for personal use which I can share. http://dev.gentoo.org/~kosmikus/ghc-cvs-6.3.ebuild You can download the ebuild, place it in your local portage overlay, for instance in /usr/local/dev-lang/ghc, create a digest, and then emerge it to build an up-to-date ghc from cvs. Please note that I do not officially support this build, so if you have problems, please do not write bug reports to Gentoo, but ask me personally. There's a small problem even then: Just a few days ago, I wanted to test HOpenGL for something and noticed the following (which happens both with the CVS version and with 6.2.1): $ ghci-cvs -package OpenGL ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package OpenGL ... ghc-6.3: can't load .so/.DLL for: GLU (/usr/lib/libGLU.so: undefined symbol: glPixelStorei) I noticed that a similar problem has been discussed a while ago on the hopengl mailing list, and according to that thread, I found a solution, namely to edit ghc's package.conf file and to make sure that -lGL comes before -lGLU in extra_ld_opts. However, because it has been discussed before, I am surprised that I still suffer from this problem. Am I doing something wrong? Is there something I can do to fix this problem in the ebuild? Best, Andres
Andres Loeh wrote:
[...] There's a small problem even then:
Just a few days ago, I wanted to test HOpenGL for something and noticed the following (which happens both with the CVS version and with 6.2.1):
$ ghci-cvs -package OpenGL ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done. Loading package OpenGL ... ghc-6.3: can't load .so/.DLL for: GLU (/usr/lib/libGLU.so: undefined symbol: glPixelStorei)
I noticed that a similar problem has been discussed a while ago on the hopengl mailing list, and according to that thread, I found a solution, namely to edit ghc's package.conf file and to make sure that -lGL comes before -lGLU in extra_ld_opts. [...]
*sigh* This seems to be a NeverEnding Story (tm)... :-P It works fine on my SuSE x86 Linux (8.2 and 9.1) Just to be sure: What exactly does work and what doesn't on Gentoo? * Building an executable using OpenGL with GHC 6.2.1 * Calling ghci (6.2.1) with "-package OpenGL" * and the same two tests with the current CVS HEAD It would be good to know all 4 combinations. Meanwhile I'll try to dig out a few old emails on this topic. Differences like this even between two Linuxes are really annoying... For further information on this refreshing topic, see: http://research.microsoft.com/~daniel/unix-haters.html :-} Cheers, S.
I wrote:
[....] Meanwhile I'll try to dig out a few old emails on this topic. [...]
I've found the relevant thread on this mailing list: http://www.haskell.org//pipermail/hopengl/2003-December/000459.html In a nutshell: It seems to be the case that the OpenGL-related dynamic libs on Gentoo are broken, they are probably missing some dependency information. Could you confirm this? Cheers, S.
I wrote:
[....] Meanwhile I'll try to dig out a few old emails on this topic. [...]
I've found the relevant thread on this mailing list:
http://www.haskell.org//pipermail/hopengl/2003-December/000459.html
In a nutshell: It seems to be the case that the OpenGL-related dynamic libs on Gentoo are broken, they are probably missing some dependency information. Could you confirm this?
Thanks for the pointer -- I had seen some other thread, but not this one. The dependencies still seem to be "broken" in Gentoo, but apparently SuSE also patches, so it's really broken somewhere else. So, if I understand the situation correctly: reversing the library order in package.conf may work for ghci, and might not do any further harm under Linux at all, but generally is not a good solution because it breaks compilation on some other platforms. Therefore it would be better to integrate the dependencies between the libararies properly into the .so files. How that can be done, I have no clue -- I really am no C programmer; but you gave the hint with the SuSE source rpm, so I have a place to start. I will try to investigate further ... Andres
Oh, one extra tip, now for any Gentoo user trying to build the GHC CVS : For some reason the bootstrap/build process for GHC CVS would not build the the alex within the build tree first, and then use that for the rest of the build, But, there is an ebuild for a recent version of alex. So there is no real hassle at all for Gentoo users. The ebuild is masked, with ~x86, but therefore does build fine at least on x86 systems (including AMD 32 bit). so just run: ACCEPT_KEYWORDS="~x86" emerge alex and then build your GHC CVS. cheers, John
Andres Loeh wrote:
Thanks for the pointer -- I had seen some other thread, but not this one. The dependencies still seem to be "broken" in Gentoo, but apparently SuSE also patches, so it's really broken somewhere else.
Hmmm, I've just had a look at the Gentoo package list and the Mesa version seems to be 3.5, which is almost 3 years old. Is this really what is used on current Gentoo systems? There have been tons of bug fixes and feature additions since then in the Mesa libs.
So, if I understand the situation correctly: reversing the library order in package.conf may work for ghci, and might not do any further harm under Linux at all, but generally is not a good solution because it breaks compilation on some other platforms. Therefore it would be better to integrate the dependencies between the libararies properly into the .so files.
Exactly. The GNU ld pages are quite clear about the order of archives, see the description of the -l option: http://sources.redhat.com/binutils/docs-2.15/ld/Options.html "The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again. See the -( option for a way to force the linker to search archives multiple times." After reading this, it is a miracle for me why the order doesn't seem to matter on my SuSE Linux... %-] Cheers, S.
Andres Loeh wrote:
Thanks for the pointer -- I had seen some other thread, but not this one. The dependencies still seem to be "broken" in Gentoo, but apparently SuSE also patches, so it's really broken somewhere else.
Hmmm, I've just had a look at the Gentoo package list and the Mesa version seems to be 3.5, which is almost 3 years old. Is this really what is used on current Gentoo systems? There have been tons of bug fixes and feature additions since then in the Mesa libs.
This is an excerpt from Gentoo's package.mask file: # Only use the mesa and mesa-glu provided with x11-base/xfree, # as the external ones gives problems in most cases with DRI/DRM. # Nvidia users do not use it anyhow, and tdfx users report that # it works fine with the mesa included with xfree. If you do # unmask these, make sure that you know what you are doing, and # know that if anything breaks, then you get to keep the pieces. # # azarah (26 May 2002)
=media-libs/mesa-3.0 =media-libs/mesa-glu-3.0 =media-libs/sgi-oss-glu-1.0 =media-libs/oss-opengl-glu-1.0
This means that the 3.5 mesa package is masked and cannot be used by Gentoo users except if they edit the package.mask file first. I do not know if the reason still applies, though. On the other hand, the xfree-4.3.0-r6.ebuild does indeed read PROVIDE="virtual/x11 virtual/opengl virtual/glu virtual/xft" I'd still like to solve the whole problem, but I can not invest many hours right now. I'll see what I can do ... Best, Andres
Andres Loeh wrote:
[...] I'd still like to solve the whole problem, but I can not invest many hours right now. I'll see what I can do ...
I've just commited a fix in the CVS HEAD for GHC which should make dynamic linking more robust. Could you check if GHCi + OpenGL/GLUT now works on your Gentoo? Updating fptools/ghc/compiler/ghci/Linker.lhs only is enough if you have a recent build tree on your disk, BTW. Cheers, S.
Andres Loeh wrote:
[...] I'd still like to solve the whole problem, but I can not invest many hours right now. I'll see what I can do ...
I've just commited a fix in the CVS HEAD for GHC which should make dynamic linking more robust. Could you check if GHCi + OpenGL/GLUT now works on your Gentoo? Updating fptools/ghc/compiler/ghci/Linker.lhs only is enough if you have a recent build tree on your disk, BTW.
Seems to work. Thanks. I will try to update Gentoo's 6.2.1 ebuild with the patch, too. Best, Andres
Sven Panne wrote:
So, if I understand the situation correctly: reversing the library order in package.conf may work for ghci, and might not do any further harm under Linux at all, but generally is not a good solution because it breaks compilation on some other platforms. Therefore it would be better to integrate the dependencies between the libararies properly into the .so files.
Exactly. The GNU ld pages are quite clear about the order of archives, see the description of the -l option:
http://sources.redhat.com/binutils/docs-2.15/ld/Options.html
"The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again.
See the -( option for a way to force the linker to search archives multiple times."
After reading this, it is a miracle for me why the order doesn't seem to matter on my SuSE Linux... %-]
Regarding the above citation, note that an "archive" is a *static*
library (i.e. a ".a" file). The ordering doesn't matter for linking
dynamic libraries.
However, if any of the shared libraries which are listed in
package.conf are missing dependency information, then the ordering
will matter for dynamic loading (e.g. for ghci). And the ordering
needs to be the reverse of that for linking static libraries.
When linking static libraries, the consumer must be listed first, so
that when the linker gets to the provider it knows which objects are
required. An archive (".a") file is just a container of object (".o")
files (conceptually similar to a ".zip" file). The linker effectively
extracts only those object files which are known to be required, and
links them in as it would any object files which were listed on the
command line.
When loading dynamic libraries at run time with dlopen() (or
equivalent), the provider must be be loaded before the consumer
(unless the consumer lists the provider as one of its dependencies),
otherwise loading the consumer may[*] fail due to an undefined symbol.
[*] Depending upon the OS and the flags passed to dlopen(). On Linux,
it depends upon whether dlopen() was called with RTLD_LAZY or
RTLD_NOW. Using RTLD_LAZY allows for undefined symbols; however, if
they don't actually get provided, calling a function which requires
them will result in sudden termination of the program. OTOH, using
RTLD_NOW would result in dlopen() failing (returning NULL), which is
easier to handle.
Whereas "ld" expects some symbols to be undefined at intermediate
stages of the linking process, and only complains if any symbols
remain undefined at the end, a call to dlopen() may require that no
symbols remain undefined upon its return. The fact that an undefined
symbol could be provided by a subsequent dlopen() doesn't help.
If the library lists in package.conf are being used for both purposes
(i.e. ld and dlopen()), they should probably processed in opposing
directions for dlopen() vs ld.
--
Glynn Clements
Glynn Clements wrote:
Regarding the above citation, note that an "archive" is a *static* library (i.e. a ".a" file). The ordering doesn't matter for linking dynamic libraries.
Sorry, I should have been clearer: The citation makes it clear that reversing the order will *definitely* lead to trouble when linking statically (e.g. on Solaris, IIRC).
[...] If the library lists in package.conf are being used for both purposes (i.e. ld and dlopen()), they should probably processed in opposing directions for dlopen() vs ld.
This sounds like a cunning idea and should be easy to implement, :-) probably by reversing "dlls" in the following line of Linker.linkPackage: ... mapM_ (load_dyn dirs) dlls ... SimonM? Cheers, S.
Hi ppl, i thought i would add some comments, being a Gentoo user: On Wed, 19 May 2004 03:38 am, Andres Loeh wrote:
I have a ghc-cvs ebuild for personal use which I can share. http://dev.gentoo.org/~kosmikus/ghc-cvs-6.3.ebuild You can download the ebuild, place it in your local portage overlay, for instance in /usr/local/dev-lang/ghc, create a digest, and then emerge it to build an up-to-date ghc from cvs.
groovy, ta. I have my own shell scripts as well, to automate the build process from CVS, but this may make things even easier. The Gentoo ebuild system is excellent.
There's a small problem even then: Just a few days ago, I wanted to test HOpenGL for something and noticed the following (which happens both with the CVS version and with 6.2.1):
$ ghci-cvs -package OpenGL ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done. Loading package OpenGL ... ghc-6.3: can't load .so/.DLL for: GLU (/usr/lib/libGLU.so: undefined symbol: glPixelStorei)
I recently built GHC CVS on my Gentoo linux and I did have problems which i think were with the hopengl if i recall correctly. i also had problems with objectio, either in the snapshot or CVS or both, but the build was fine when objectio was not enabled. BUT, the ghc-6.3.20040504 CVS snapshot was OK. It compiles HopenGL apps fine, eg the glxgears app that was recently posted on this list. I havent tried running any HopenGL apps with the ghci from that snapshot tho. It is a shame the Redbook examples have not yet been modified also, to suit the new GHC package inclusion syntax tho :( I will run those tests that Svenne suggested and post my results, both for the ghc-6.3.20040504 CVS snapshot and the latest CVS. But not tonight. cheers, John
participants (5)
-
Andres Loeh -
Glynn Clements -
jss＠au.mensa.org -
Sven Panne -
Weeble