This is a new ebuild for PolyML, a open source SML compiler. The home page is at http://www.polyml.org. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 21993 [details] New Ebuild
Is there any idea when this will be definitely added to portage?
I've tried this ebuild and it seems to work - well enough for me to compile the OpenProofPower system. I would like to see this ebuild included, since it would simplify the inclusion of OpenProofPower into gentoo (OpenProofPower can be built with another system, in theory, but the polyml build is more straightforward.) Is it the funky license that's slowing things down? In any case, thanks for making the ebuild!
polyml segfaults for me. First some suggestions for the ebuild: 1. set S="${WORKDIR}/driver" and remove those cd commands 2. die if make or BuildAll.sml fail 3. It would be nice to honour portage's idea of CFLAGS: (after econf) sed -i "s!s,@OPTFLAGS@,-g -O2 -Wall,g!s,@OPTFLAGS@,${CFLAGS},g!" \ config.build && sed -f config.build < Makefile.in > Makefile || die I have traced the SIGSEG to the following call: #0 ReserveAddressSpace (addr=0x3f000000 <Address 0x3f000000 out of bounds>, len=8192) at mmap.c:364 #1 0x080591fe in ReserveMLSpace ( bottom=0x3f000000 <Address 0x3f000000 out of bounds>, top=0x3f002000 <Address 0x3f002000 out of bounds>) at mmap.c:378 #2 0x080592f1 in ReserveMLSpaces () at mmap.c:406 #3 0x080521f3 in main (argc=1, argv=0xbfffe4f4) at mpoly.c:710 According to threads on the polyml mailing list at http://lists.inf.ed.ac.uk/mailman/listinfo/polyml this is a problem somehow related to linux 2.6.9 SMP. I'll try to stay tuned to this list.
Created attachment 45694 [details] Enhanced ebuild This ebuild includes the improvements mentioned above in comment#4.
Created attachment 46519 [details, diff] 4.1.3-address.diff This solves the segmentation fault for me. I hope the polyml mailing list will either confirm this approach or offer some other solution to be included here.
Created attachment 46520 [details] Improved ebuild - ${A} instead of /usr/portage/distfiles/... => portability - unpack instead of tar invocation - do* instead of cp - epatch to apply attachment#46519 [details, diff]
So far, my patch from comment 5 seems to work for everybody, so this could be included as well. I just found out that it seems like Poly/ML has been removed from the portage tree. Why is this? According to an email posted today by David Matthews, a new Poly/ML release will soon be available, and it will be licensed under LGPL.
The virtual/glibc dependency seems to be no longer valid, it should probably be virtual/libc now. Is there some reason why this ebuild has not been included yet?
Re-assign.
Created attachment 74275 [details] polyml-4.2.0.ebuild I wrote an ebuild for the latest Poly/ML which is version 4.2.0. Poly/ML is now licensed under the LGPL-2.1. I changed the configuration process, now I'm replicating the workings of configure manually. As a result the X USE flag is honoured, and theoretically things should also work for ppc and sparc, although I don't have the machines to try this.
Created attachment 74276 [details, diff] 4.2.0-stack-noexec.patch This patch is used by attachment #74275 [details] to prevent portage from issuing a security warning because of executable stack segments. This has only been tested for x86 so far, but has already been reported upstream, so I expect further tests on other architectures in the near future.
PolyML 5 has been released. From http://lists.inf.ed.ac.uk/mailman/private/polyml/2007-January/000266.html: > I have updated the web site to release version 5 officially. There is a > source package available at > http://sourceforge.net/project/showfiles.php?group_id=148318 . > > Thank you everyone who provided feedback during the beta test phase. > > If anyone wants to make binary distributions that would be very welcome. > I am hoping that will be easier now that it uses autoconf, and of > course now it is licensed under LGPL. Please post a message to this > list if you make a distribution so that I and other people know about > it. I'm hoping to produce a Windows binary shortly. > > Bug fixes and other updates will continue to be made to the CVS version > and will be incorporated into the next release when it happens. > > David.
Gezz, this bug is almost as old as I am... :) It doesn't seem there is a maintainer yet!
Either find a maintainer, or if you want to maintain it yourself, feel free to reopen and join project sunrise, details here: http://www.gentoo.org/proj/en/sunrise Thanks. WONTFIX meanwhile.
Created attachment 170959 [details] Ebuild for Poly/ML 5.2.1 For what it's worth, Poly/ML 5.x has a much simpler build process.
cc-ing ML team instead of sci, see if they are interested. Thanks for the ebuild.
(this is an automated message based on filtering criteria that matched this bug) Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accomendate you on a timely manor. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
polyml-5.2.1 is now in main. SML really needs a dedicated developer though.
(In reply to comment #19) > polyml-5.2.1 is now in main. Compiles and seems to work on ~x86, please add keyword.
Please file a new bug for that. I cannot add that keyword for you.
