drscheme needs bump to 370
Hi, I would also appreciate if the maintainer could update dev-scheme/drscheme to at least version 369. Took a look at the ebuild, but it seems to require some tricks to get this thing installed and so I didn't succeed with my basic ebuild knowledge. Thanks in advance Martin
So, I decided to give the version bump a whack, but I've hit a wall. I've updated the ebuild and fixed one of the patches for the new version (the other one still works), but don't use them except for testing, as they don't work >_<. The biggest difference in the new version is that the 3m collector is now the default upstream, with the cgc now being optional. Here's the problem, after a certain time I hit this compile error: --- standard-module-name-resolver: collection not found: #<path:compiler/private> in any of: (#<path:/home/non-user/tmp/portage/dev-scheme/drscheme-370-r1/work/plt-370/src/mred/gc2/xform-collects>) --- Even though when I check afterwards, /home/non-user/tmp/portage/dev-scheme/drscheme-370-r1/work/plt-370/src/mred/gc2/xform-collects/compiler/private does exist. not sure what to do at this point, so I'll attach the relevant files and let someone else take a stab at it. >_<
Created attachment 124163 [details] 370 ebuild (DOESN'T WORK) My try at the version bump, but it doesn't compile successfully.
Created attachment 124165 [details, diff] New version of DESTDIR patch for 370 Manually went through the new Makefile.in applying the changes manually (too many changes in the new version for it to apply cleanly), then remade the patch with diff.
Created attachment 124167 [details] build log for failed 370 ebuild
Created attachment 124924 [details, diff] Old fPIC patch still being used Just so that non-gentoo users can still see all the applied patches.
Hi Hendrik, fortunately today I remembered again the important rule that strange build failures can occur from build systems with broken support for parallel building. Using this line, it should compile: MAKEOPTS="-j1" emake || die "emake failed" I'll probably fix this soon now.
(In reply to comment #7) > Hi Hendrik, fortunately today I remembered again the important rule that > strange build failures can occur from build systems with broken support for > parallel building. Using this line, it should compile: > > MAKEOPTS="-j1" emake || die "emake failed" > > I'll probably fix this soon now. > Yup, just found today that it works when you add -j1 to the first (3m) emake. emake -j1 || die "emake failed" In fact, you could probably remove it from the second (cgc) emake as well without trouble, as that's how it was in the last version. Thanks, Hendrik Boom
I have an ebuild that compiles, but it needs more work. I am on vacation at the moment, I should be able to commit it shortly after I get back next week.
It seems that the internal libtool version is broken when using --enable-shared. In a day or so an updated version should be available from [http://pre.plt-scheme.org/installers/].
no luck with 370.6
Created attachment 125867 [details] drscheme-999999.ebuild I worked with upstream to get all issues I was having fixed. This live ebuild which is also in our overlay works for now. To release 370 we need to patch at least configure to the new version. llvm use flag should be made to do something. Unfortunately prerelease version numbers do not change for every nightly build or we could release 370.6 or 370.7... We could also just take 370.6 and host it.
(In reply to comment #12) > llvm use flag should be made to do something. Never mind, it already does something.
Comment on attachment 125867 [details] drscheme-999999.ebuild bug fixed live ebuild in our overlay, #gentoo-lisp for more info. I will probably commit an ebuild for tonights snapshot tomorrow.
fixed, lots of nasty QA messages at the end though.
reopening until drscheme doesn't segfault anymore and is unmasked again.
fixed now
