RE: Patches for NetBSD port and automatic .hc bootstrap (long)

below find a set of patches that hopefully should fix the following for ghc-5.04.3:
1. (re-)port to NetBSD/i386. - the last GHC to work for NetBSD was 4.04, I think. Since then, both GHC and NetBSD has changed a lot...
2. restore the ability to do an automatic bootstrap from .hc files. - at least the updated distrib/hc-build script runs to completion without errors for me now on NetBSD/i386, and the resulting compiler seems to work fine (at least it is able to compile itself once again). All this on a system with no previous GHC installed.
I think most of the patches should be more or less self-explanatory. But please feel free to ask if something looks strange.
Thanks, I've committed most of your patches...
I will just mention one problem I had, that I think needs a cleaner solution. This is marked "XXX_UB" in the patches below.
The problem is the readline library in NetBSD. There is one readline in the base system (/usr/include and /usr/lib) but that is not the GNU readline that GHC expects. Instead the readline in /usr/pkg/include and /usr/pkg/lib must be used. The GCC in NetBSD does not include the /usr/pkg paths by default, so we must pass explicit -I/-L/-R all the time when using it. In particular this:
-L/usr/pkg/lib -Wl,-R/usr/pkg/lib
needs to go into hslibs/util/util.conf.in. And the same needs to go into ghc/rts/rts.conf.in for libgmp. I had to invent two new configure variables to make this work, ExtraLdOptsReadline and ExtraLdOptsGmp. Sofar this is OK I think, other systems should be able to use these too if they have readline or gmp installed in non-standard places.
However, the problem is how to set these variables in the configure script. Below you can see the hack I did for NetBSD, but that is not very elegant. Maybe a better solution would be to add --with-readline=... and --with-gmp=... options to the configure script? This would at least partly solve the problem.
Yes, I think this would be a better solution - at least more consistent with the way configure handles other such things. The right thing to do is to add --with-readline-includes=... --with-readline-libraries=... and --with-gmp-includes=... --with-gmp-libraries=... Incidentally, why are the -Wl,-R<dir> options needed? I've never come across that before, usually the runtime linker just finds the libraries in the place they were originally linked from.
I will also update the NetBSD package (port) with these patches. I think I will try to keep the package booting from .hc files rather than going the "first download small binary bootstrap kit" route that you guys seem to have chosen for FreeBSD nowadays. It seems to me that although booting from .hc files is very fragile business it has the advantage that it makes the package less sensitive to the exact OS versions involved (in particular the version the binary bootstrap kit was built on).
Note that HC files can also be platform dependent, since they depend in some cases on the values of symbols from config.h. We used to try to keep .hc files completely platform-independent, but I've come around to the conclusion that this isn't a realistic goal. As soon as you use a platform-dependent #ifdef or #define in the Haskell source (and we do that a fair bit in the libraries and even the compiler), the property is lost. So, while one set of .hc files might work for all the versions of NetBSD you want to build the compiler on, we don't guarantee it. Cheers, Simon

Simon Marlow wrote:
Incidentally, why are the -Wl,-R<dir> options needed? I've never come across that before, usually the runtime linker just finds the libraries in the place they were originally linked from.
The runtime linker will use the first matching library it finds, which
isn't necessarily the same one that was used in the linking step. The
-R switch will cause the runtime linker to search specified directory
before the "normal" library directories (e.g. /usr/lib).
--
Glynn Clements

Simon Marlow writes:
Simon> I've committed most of your patches... Great, thanks for the quick response!
-L/usr/pkg/lib -Wl,-R/usr/pkg/lib
Simon> Incidentally, why are the -Wl,-R<dir> options needed? Ah, yes, I guess I should have commented on that. In its continuous quest to do things The Right Way (TM), NetBSD has decided to not do what many other systems do, i.e., automatically add linker run path flags for each -L flag. Instead you must give explicit run path flags for each runtime library location. Really, this makes a lot of sense if you think about it. There is no reason that a library should be located at the same place during both build time and run time (think cross compiling and such). The NetBSD runtime linker can also use things like /etc/ld.so.conf and LD_LIBRARY_PATH, for executables that don't have correct rpaths in them, but you can't trust /usr/pkg/lib to be found that way for all NetBSD systems. Simon> Note that HC files can also be platform dependent, since they Simon> depend in some cases on the values of symbols from config.h. Simon> We used to try to keep .hc files completely Simon> platform-independent, but I've come around to the conclusion Simon> that this isn't a realistic goal. OK, I figured that it was something like that. Simon> So, while one set of .hc files might work for all the versions Simon> of NetBSD you want to build the compiler on, we don't guarantee Simon> it. Sure, I understand that. So do you know the reason that the FreeBSD port was changed to build via this binary kit rather than from .hc files? Kind regards, -- Urban
participants (3)
-
Glynn Clements
-
Simon Marlow
-
Urban Boquist