Right now the scheme48vm is build with "-m32" on AMD64 platforms; the modified ebuild rebuilds the source from scratch (using the patch http://people.csail.mit.edu/riastradh/tmp/s48-64.patch, changed in a few lines) and enables a full 64bit version (therefore dynamic linking works now fine for me). Rebuilding needs some files of Unicode data which are in the perl distribution (or on the net) - i didn't think it's necessary to add them to the files / an error message is displayed if absent. Reproducible: Always Steps to Reproduce:
Created attachment 132097 [details, diff] ebuild Patch
Created attachment 132102 [details, diff] Modified source patch
Hi Olof, great work, but you should really get upstream to accept this patch. I wondered at a few things in the ebuild patch: 1) +amd64? ( dev-scheme/scheme48 )" What's the purpose of this? To install scheme48 on amd64 you need to have it already installed, but to do that you need it already installed... etc. 2)dying if UnicodeData.txt is not where it is needed is unacceptable.
Hello Marijn, > great work, but you should really get upstream to accept this patch. Well, its not in 1.7, but in that case i would work on it ... > 1) +amd64? ( dev-scheme/scheme48 )" > What's the purpose of this? To install scheme48 on amd64 you need to have it > already installed, but to do that you need it already installed... etc. In the Makefile, at "i-know-what-i-am-doing" we need a runnable scheme, possibly any other scheme available (though i don't know right now which one works for this (and something like virtual/scheme doesn't exists)), for creating the c sources. so i meant: building with x86 for getting a runnable scheme and then emerging a second time for getting a bootstrapped scheme for amd64. > 2)dying if UnicodeData.txt is not where it is needed is unacceptable. It is needed when rebuilding, so ... what is the appropriate way to get the files in that case (if not manually like now)?
(In reply to comment #4) > In the Makefile, at "i-know-what-i-am-doing" we need a runnable scheme, > possibly any other scheme available (though i don't know right now which one > works for this (and something like virtual/scheme doesn't exists)), for > creating the c sources. so i meant: building with x86 for getting a runnable > scheme and then emerging a second time for getting a bootstrapped scheme for > amd64. I see. The scheme48 sources are pure scheme48 and we need a precompiled scheme48 to bootstrap. (There is no virtual/scheme because the differences between implementations are just too great and almost all programs will make use of implementation-dependend extensions, so there would be no use for it.) SBCL has a similar problem and it currently downloads a precompiled version from upstream to compile the source with. Of course this depends on upstream providing binaries for your architecture and it currently also doesn't deal make use of your own compiled version to compile new versions. GHC may have a better solution to this problem. > > 2)dying if UnicodeData.txt is not where it is needed is unacceptable. > It is needed when rebuilding, so ... what is the appropriate way to get the > files in that case (if not manually like now)? You need to put it into place automatically. If it is not in the normal sources, then we could put a copy in the files/ subdir or if it is too big mirror it separately and put it in SRC_URI or if these files are already in some perl package we could depend on that and copy them over from ROOT or something.
Created attachment 132306 [details, diff] ebuild Patch
Created attachment 132308 [details] Needed unicode data
Comment on attachment 132308 [details] Needed unicode data If 150k is small enough, than thats it.
the 1.8 release of scheme48 compiles natively on amd64.
