Find attached an ebuild and patch for the latest upstream release of GNU Prolog.
Created attachment 75583 [details] gprolog-1.2.19.ebuild
Created attachment 75584 [details, diff] gprolog-1.2.19-CFLAGS.patch
Hi Keri. Sorry, I did not get to your ebuilds earlier - I was tying up some staff in Ada land, but now the "small" stuff is done and I'll take at prolog, before going back :). Thanks for the submission. I have couple of questions though. But first: it is usually better to submit diffs when you post a new version of ebuild or whatever - makes the changes immediately visible.. But is the package already released? I see on the gprolog homepage that they advertise only 1.2.16 so far, plus I cannot fetch sources for this one, does not look like it is on gnu's mirrors.. This, below, is just from looking at the changes in ebuild src_unpack 1. ># Fix gplc executable stack creation >sed -i -e "s/EXE_FILE_ASM, \" \", \"-o/EXE_FILE_ASM, \" \", \"--noexecstack -o/" TopComp/top_comp.c I presume this is in the responce to those annoying QA messages? However is this safe for gprolog? I am not sure whether nested functions make any sense in prolog land (one of the things this might interfer with), but the major reason for killing the execution of stack was to guard C/C++, which is not as a severe problem with pretty much all other languages. Anyway, the only way to know is to test. Are there any comprehensive test suits that would pick something like that up? 2. CFLAGS_MACHINE="`get-flag -march`" CFLAGS_MACHINE="${CFLAGS_MACHINE} `get-flag -mcpu`" CFLAGS_MACHINE="${CFLAGS_MACHINE} `get-flag -mtune`" Does gprolog have any relation to gcc? If yes, then 2nd and 3rd lines may not be necessary, -march is supposed to imply the others. However I see you filter them later from CFLAGS, so this is probably necessary for that (and it does not heart to have them anyway). src_compile 3. cd "${S}" at the beginning of src_compile and src_install is not necessary. 4. It is probably better to move definition of CFLAGS_MACHINE and filter-flags here - they do not touch sources, so technically they do not deal with unpacking but have a logical relationship with compiling.. George PS I see it is not that easy to intersect on irc for us, as you are in NZ and I am in Europe, but feel free to ping me (just join #gentoo)or /msg me directly if you have any questions. I'll try to find you after I'll go through all the prolog bugs..
Oh, forgot one more thing: in the provided patch, these lines: +echo $CFLAGS +echo $CF1 +echo $CFLAGS_MACHINE Are they necessary for something or are they leftover debug output? If you want to keep them it is usefull to add a comment as of their effect in the code.. George
Created attachment 75845 [details, diff] gprolog-1.2.19-CFLAGS.patch
Created attachment 75846 [details, diff] gprolog-1.2.19.ebuild.patch I've tidied up the ebuild and patch, correcting SRC_URI and removing the superfluous echos in the patch. gprolog makes a firm distinction between machine-specific CFLAGS (-march, -mcpu and -mtune) and architecture independent CFLAGS. Any machine-specific CFLAGS are filtered from $CFLAGS and passed to the configure script via $CFLAGS_MACHINE. Regarding gplc generating binaries with an executable stack - gplc essentially acts as a wrapper for 'gcc' and 'as' when dealing with imported c predicates. (gplc can even be used to compile and link standalone c programs). Thus it inherits all the problems with safeguarding the stack for imported c code. To illustrate, here's an example of running a prolog program with c bindings that will execute /bin/sh from the stack (the programs are attachments to follow): $ ls stack_test.c stack_test.pl $ gplc stack_test.pl stack_test.c $ ls stack_test stack_test.c stack_test.pl $ ./stack_test GNU Prolog 1.2.19 By Daniel Diaz Copyright (C) 1999-2005 Daniel Diaz | ?- stack_test. sh-3.00$ exit exit What is problematic is that the binary generated by gplc always has its stack marked as executable: $ scanelf -e ./stack_test TYPE STK/REL/PTL FILE ET_EXEC RWX --- RW- ./ex I'm not aware of GNU Prolog's resolution engine requiring an executable stack, but have nevertheless raised the issue of executable stacks with upstream and am awaiting a reply. In the meantime I'm happy to let the ebuild go with the QA warnings. :)
Created attachment 75847 [details] stack_test.pl
Created attachment 75848 [details] stack_test.c The above two attachment comprise a prolog program with c bindings. To compile: $ gplc stack_test.pl stack_test.c To execute: $ ./stack_test When in the prolog interpreter, the dodgy c code can be called via the predicate 'stack_test': | ?- stack_test.
Thanks for an update Keri. Here is what I get on amd64: [ ! -f pl2wam ] || cp pl2wam pl2wam0 gplc -o pl2wam --no-fd-lib --min-bips pl2wam.o read_file.o bip_list.o syn_sugar.o internal.o code_gen.o reg_alloc.o inst_codif.o first_arg.o indexing.o wam_emit.o make[1]: Leaving directory `/var/tmp/portage/gprolog-1.2.19/work/gprolog-1.2.19/src/Pl2Wam' make[1]: Entering directory `/var/tmp/portage/gprolog-1.2.19/work/gprolog-1.2.19/src/Fd2C' gplc -c --fast-math fd2c.pl Fatal Error: Segmentation Violation compilation failed make[1]: *** [fd2c.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/gprolog-1.2.19/work/gprolog-1.2.19/src/Fd2C' make: *** [all] Error 1 !!! ERROR: dev-lang/gprolog-1.2.19 failed. !!! Function src_compile, Line 43, Exitcode 2 !!! emake failed This does not seem to depend on CFLAGS or MAKEOPTS (it just -jX now - for parallel build). But then, amd64 was not in KEYWORDS, I just added it to test, since there were no apparent arch restrictions (and configure did not complain either). Well, looks like there are problems on this arch.. Other than that, it compiled fine in 32bit chroot, but I have a complaint about installation phase: files COPYING, ChangeLog, NEWS, VERSION are installed plain under /usr. This is not the dodoc doing, as that one installs them (additionally) where they should be, but rather this happens during make install-system. Here is the relevant output of emerge install: for i in `echo "COPYING VERSION NEWS ChangeLog"`; do /bin/install -c -m 644 ../$i /var/tmp/portage/gprolog-1.2.19/image//usr;done Otherwise the image looks fine.. One small tip: you may easily miss stuff like that if you simply run "emerge package" when you test, for this reason I prefer to do: cd category/pkgname ebuild pkg-PV.ebuild digest unpack setup compile install Then you can cd /var/tmp/portage/package/image and look around - you will see all the files that will be installed during the (next) qmerge step by portage. This also helps a lot if you need to figure out how to move stuff around if there is a need, or what cruft can be removed.. To fix this you can simply add rm -f "${D}"/usr/{COPYING,ChangeLog,NEWS,VERSION} to src_istall, although it is better to disable installing these files in Makefile With above rm it installs and seems to work fine, although I do not know nearly enough prolog to do any sensible testing.. George
*** Bug 65076 has been marked as a duplicate of this bug. ***
Created attachment 76602 [details] gprolog-1.2.19.ebuild Find attached an updated ebuild properly respecting sane install locations for documentation. With regards to gprolog not compiling on AMD64 - this is most certainly due to gcc-3.4 not ensuring gprolog's trail stack is byte-aligned on 64-bit architectures. gprolog-1.2.17 was the first release to introduce support for x86_64, but only when compiled with <=gcc-3.3.3. gprolog-1.2.19 provided fixes for gcc-3.4 on 32-bit architectures, but 64-bit architectures have been left largely unsupported. I'll poke around a little and see what the likelihood of a fix for x86_64 with gcc-3.4 will be.
Created attachment 76980 [details, diff] gprolog-1.2.19-pl2wam-no-fast-call.patch Furthur investigations show that gprolog's finite domain constraint handler appears to be quite unsupported on x86_64 architectures when built with >=gcc-3.4. It may be possible to build it with a version of pl2wam that does not use fast-math calls, but this is pure speculation and I'm not confident that this will fix the build problems; in any case, I've attached a patch that can be applied to see if this is the case. ('--disable-fast-call' will also need to be passed to econf). If the build still fails, then an strace of '../Pl2Wam/pl2wam fd2c.pl' from within the directory gprolog-1.2.19/src/Fd2C/ may provide some insight into why the build is failing. If this fails to resolve this issue, then an interim solution is to simply disable gprolog's finite domain solver (which is not part of the core distribution) for amd64.
Created attachment 77876 [details, diff] gprolog-1.2.19.ebuild.patch Find attached an ebuild patch for gprolog-1.2.19 that addresses several issues: 1) The gprolog build does not parallelize well. I've dialed back to -j1 in MAKEOPTS. 2) I'm attaching a patch that enables gprolog to build with gcc-4.x. gprolog is horribly broken with gcc-4. This is due to gprolog using a rather strange symbol-address scheme: when a gplc-compiled binary calls a prolog predicate, the executable file is searched, looking for obj_chain structures. As these structures are found, the requested predicate initialization is called. Unfortunately, at link-time the obj_chain *relied* on earlier versions of gcc allowing us to mix extern and static definitions in header files. The patch renames the start and end of each obj_chain structure approprately, ensuring that initialization routines are called. (This area of gprolog is nasty to look at!) 3) gprolog built with gcc-4 cannot take advantage of fast-calls. In particular foreign_double calls are not byte-aligned and will break any code relying to them. fast-math calls are now disabled on gcc-4 builds. 4) when building with gcc-4, gprolog cannot use -O optimizations, and "-O0" must be used. Even "-O1 -fno-everthing-enabled-by-O1" causes the gprolog build to fail - this is an indication of just how dependent upon specific compiler and linker behaviour gprolog's obj_chain is. 5) With "maketest" in FEATURES, foreign call_c test routines and obj_chain tests are now conducted. These provide a good indication of gprolog's ability. (patch to follow). (The gcc patch has been sent upstream). George, your error with building fd2c on amd64 may be the same as the issue raised in point 1); the build is failing at the same place. I'm interested to see how it builds with the updated ebuild and patches. :)
Created attachment 77877 [details, diff] gprolog-1.2.19-gcc4.patch
Created attachment 77878 [details, diff] gprolog-1.2.19-test.patch
Created attachment 77891 [details, diff] gprolog-1.2.19.ebuild.patch A slight modification to fast-call checking on non-x86 architectures.
Created attachment 77892 [details, diff] gprolog-1.2.19-test.patch A slight modification to fast-call checking on non-x86 architectures.
It emerged for me on 2 PCs, but with QA exec-stacks notice (same on both PCs): man: prepallstrip: strip: i686-pc-linux-gnu-strip --strip-unneeded /usr/bin/fd2c /usr/bin/gplc /usr/bin/ma2asm /usr/bin/pl2wam /usr/bin/gprolog /usr/bin/hexgplc /usr/bin/wam2ma QA Notice: the following files contain executable stacks Files with executable stacks will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the file is fixed. Please include this file in your report: /var/tmp/portage/gprolog-1.2.19/temp/scanelf-exec.log RWX --- --- usr/bin/fd2c RWX --- --- usr/bin/pl2wam RWX --- --- usr/bin/gprolog !WX --- --- usr/lib/all_fd_bips.o !WX --- --- usr/lib/top_level.o !WX --- --- usr/lib/all_pl_bips.o !WX --- --- usr/lib/debugger.o >>> Completed installing gprolog-1.2.19 into /var/tmp/portage/gprolog-1.2.19/image/ the 1st PC's # emerge --info Portage 2.1_pre5-r3 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r7 i686) ================================================================= System uname: 2.6.15-gentoo-r7 i686 Intel(R) Celeron(R) CPU 2.00GHz Gentoo Base System version 1.12.0_pre16 ccache version 2.4 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-Os -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ ftp://ftp.dtiltas.lt/mirror/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/" LC_ALL="lt_LT.utf8" LINGUAS="lt" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac aalib acpi alsa apm artworkextra asf audiofile avi bash-completion berkdb bitmap-fonts browserplugin bzip2 cairo cdb cdparanoia cdr chroot crypt curl dbus dri dv dvd dvdread eds emboss encode exif expat fam fat ffmpeg firefox flac foomaticdb fortran gd gdbm gif glut gnome gnutls gpm gstreamer gtk gtk2 gtkhtml hal howl idn imagemagick imlib irssi java javascript jpeg lame lcms libg++ libwww live logrotate mad matroska mikmod mjpeg mmx mmxext mng motif mozilla mp3 mpeg mplayer nautilus ncurses network nls nptl nptlonly nsplugin ntfs numeric nvidia offensive ogg oggvorbis openal opengl oss pam pdf pdflib perl pic png python quicktime readline real reiser4 reiserfs sdl shorten spell sqlite sse sse2 ssl symlink tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vidix vorbis win32codecs wxwindows xchat xine xml xml2 xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_lt userland_GNU video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LDFLAGS, PORTDIR_OVERLAY the 2nd PC's # emerge --info Portage 2.1_pre5-r3 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r7 i686) ================================================================= System uname: 2.6.15-gentoo-r7 i686 AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.12.0_pre16 ccache version 2.4 [enabled] dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -pipe -Os -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -pipe -Os -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ ftp://ftp.dtiltas.lt/mirror/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac aalib acpi alsa apm artworkextra asf audiofile avi bash-completion berkdb bitmap-fonts browserplugin bzip2 cairo cdb cdparanoia cdr chroot crypt curl dbus dri dv dvd dvdr dvdread eds emboss encode exif expat fam fat ffmpeg firefox flac foomaticdb fortran gd gdbm gif glut gnome gnutls gpm gstreamer gtk gtk2 gtkhtml hal howl idn imagemagick imlib irssi javascript jpeg lame lcms libg++ libwww live logrotate mad matroska mikmod mjpeg mmx mmxext mng motif mozilla mp3 mpeg mplayer nautilus ncurses network nls nptl nptlonly nsplugin ntfs numeric nvidia offensive ogg oggvorbis openal opengl oss pam pdf pdflib perl pic png python quicktime readline real reiser4 reiserfs sdl shorten spell sqlite sse sse2 ssl symlink tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vidix vorbis win32codecs wxwindows xchat xine xml xml2 xv xvid zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Created attachment 81345 [details, diff] gprolog-1.2.19-noexecstack.patch Thanks for the update Ernestas. I've had a good look at gprolog's implementation of the Warren Abstract Machine. It does not use nested functions so ma2asm can append a .note.GNU-stack ELF section to the generated .s files. Find attached a patch that will do this on x86 and ppc architectures. It should be noted that when gplc is ever used as a wrapper for 'as' then generated binaries will default to having executable stacks; '-A noexecstack' can be set as a assembler option to gplc if required. You can ignore the last paragraph is you are only interested in using the prolog interpreter or using gplc to compile prolog programs. :) Keri.
Created attachment 81346 [details, diff] gprolog-1.2.19-bootstrap.batch This patch ensures that the bootstrap compiler is used to compile gplc and associated tools.
Created attachment 81347 [details] gprolog-1.2.19.ebuild Updated ebuild to incorparate bootstrap and noexecstack patches.
Now everything's OK. Thanks for the patches.
bugs.g.o. seems to be responding again :), so on with the gprolog package. However it still fails on amd64, although in a somewhat different place. Well, I'll have to do a full test later at home in 32bit chroot.. Right now I just wanted to point at his block of code in ebuild: if [[ $(gcc-major-version) == "4" ]] ; then append-flags "-O0" fi local myconf if [[ $(gcc-major-version) == "4" ]] ; then myconf="${myconf} --disable-fast-call" fi There are two checks for exactly the same condition. Perhaps the "local myconf" can be moved above and both of them combined? This seemingly would produce the same effect. Otherwise the ebuild looks quite clean. I'll let you know how it tested on x86 a bit later. George
Builds fine in 32bit chroot, as before. You can add it now an close a slew of gprolog related bugs :). One last minor thing: All the patchess that are applied end in .patch, while gprolog-1.2.19-bootstrap.batch ends in .batch. Is this on purpose or simple typo? George
Thanks for the comments george. I've tidied up the two checks for gcc-4.* into one, and correctly named the bootstapping patch. And I've committed this to cvs :)
