cvs: MachCode (undeclared functions)
Hi there, Make all fails due to the fact that some functions in nativeGen/MachCode are undeclared. Log appended. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hscpp make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/mkdependHS make INSTALLING=0 BIN_DIST=0 -
RE: MachCode (undeclared functions)
Make all fails due to the fact that some functions in nativeGen/MachCode are undeclared. I checked in a change yesterday am which should make MachCode compile ok on both Linux/Win32 and Solaris, but it will not compile on Alpha (I didn't think that anyone was trying Alpha, though). So if you are using Solaris, can you 'cvs update' your tree and try again? J
cvs: Profiling.c:462: strucuture has no member named `emitted'
Hi there, I just updated cvs and now make fails because of a Profiling.c:462: strucuture has no member named `emitted' thingy. Log appended. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hscpp make[3]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/mkdependHS make
RE: Profiling.c:462: strucuture has no member named `emitted'
I just updated cvs and now make fails because of a Profiling.c:462: strucuture has no member named `emitted' thingy. Log appended. my bad; now fixed. Cheers, Simon
cvs: make boot fails: mkdependHS-inplace: can't open directory haxml/lib
Hello again, When carrying out a make boot with cvs this caused a problem because of the following: mkdependHS-inplace: can't open directory haxml/lib I have appended a log. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] ===fptools== Recursively making `boot' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make boot -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `boot' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir ../../glafp-utils/mkdependC/mkdependC -f .depend -- -- lndir.c ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb ../../glafp-utils/mkdependC/mkdependC -f .depend -- -- sgmlverb.c ===fptools== Finished making `boot' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make boot -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `boot' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `boot' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hp2ps ../../../glafp-utils/mkdependC/mkdependC -f .depend -- -O-- AreaBelow.c AuxFile.c Axes.c Curves.c Deviation.c Dimensions.c Error.c HpFile.c Key.c Main.c Marks.c PsFile.c Reorder.c Scale.c Shade.c TopTwenty.c TraceElement.c Utilities.c ==fptools== make boot - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils/hscpp ==fptools== make boot - --no-print-directory -r; in
RE: make boot fails: mkdependHS-inplace: can't open directory haxml/lib
When carrying out a make boot with cvs this caused a problem because of the following: mkdependHS-inplace: can't open directory haxml/lib Maybe you need to 'cvs update -Pd'. The haxml directory just appeared yesterday. Cheers, Simon
Re: make boot fails: mkdependHS-inplace: can't open directory hax ml/lib
Simon Marlow ([EMAIL PROTECTED]) wrote: : When carrying out a make boot with cvs this caused a problem : because of the following: : mkdependHS-inplace: can't open directory haxml/lib : : Maybe you need to 'cvs update -Pd'. The haxml directory just appeared : yesterday. Thanks. Mike Gunter also pointed me in this right direction. Regards, Marc -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
How to handle hi-file versionitis/a possible library scheme
Will ghc change interface format with each version? This is the biggest problem (and, interestingly, the least addressed :-)). Especially for binary distribution builders, it's quite inconvenient to rebuild every GHC-library on the system to match with the latest compiler version :-( I thought about a scheme similar to the TeX font-generation (if the font has already been "compiled" for a particular resolution (dpi), it's re-used; if not, it is created). But here we're talking about binary libraries, and this may rise some security issues. I had something like the following in mind: * Create a new group `ghc' on the system * The library sources are installed under sourcedir/package/ (readonly). sourcedir:=`prefix/share/ghc-libsrc/' * Create spooldir:=`/var/spool/haskell/compiler/version/' for all installed compilers. owner: root.ghc, mode: 3777 (for all dirs below spooldir) hi-files go into spooldir/package/imports/, libs to spooldir/package/ * Make those GHC programs, which write to spooldir, setgid `ghc'. This would ideally be one single program called `ghc-recompile', which has one parameter, package, and handles all the stuff to recompile a library to let it match the compiler version. Of course, ghc-recompile must be designed carefully wrt. to security, i.e. environment cleanup, maybe some protections mechanisms to let programs,scripts,etc. called from within ghc-recompile write exclusively to spooldir/package, logging, limit uids to 100+, etc... ghc-recompile has to be compiled statically to prevent possible misuse by playing tricks with library preloads, etc... * If a needed interface file/library is not found at the appropriate directory in spooldir, and if the sources are available under sourcedir, the library is recompiled. This implies, that there must be some kind of "instruction" (Makefile,script,...) in sourcedir/package/ to rebuild a library version. This script is called by ghc-recompile. So, the admin just has to install the lib sources and the compiler, and if someone wants to use an already installed library, he just _can_! (if s/he's so unfortunate to be the first user, compilation just takes longer this time). Comments? Cheers, Michael -- Of course, we all know that debian/rules... -- Joey Hess
