Bugzilla Bug 19830

GCL is currently at version 2.5.2.  Newest ebuild for GCL is 2.4.3 and doesn't
appear to be functional with newer bfd libraries on gentoo.

The following ebuild appears to build 2.5.2 correctly (based on old 2.4.3 ebuild):

# Distributed under the terms of the GNU General Public License v2
# $Header: /home/cvsroot/gentoo-x86/dev-lisp/gcl/gcl-2.5.2.ebuild,v 1.6
2003/02/13 10:53:50 vapier Exp $

S=${WORKDIR}/${P}
DESCRIPTION="GNU Common Lisp"
SRC_URI="ftp://ftp.gnu.org/gnu/gcl/gcl-${PV}.tar.gz"
HOMEPAGE="http://www.gnu.org/software/gcl/gcl.html"
PROVIDE="virtual/commonlisp"

DEPEND=">=app-text/texi2html-1.64
	>=dev-libs/gmp-4.1"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="x86"

src_compile() {

	cd ${S} ;  echo `pwd`
	./configure --disable-statsysbfd --enable-locbfd --prefix=/usr || die

	cd ${S}
	make || die

}

src_install() {

	dodir /usr/share/info
	dodir /usr/share/emacs/site-lisp/gcl

	make install prefix=${D}/usr MANDIR=${D}/usr/share/man \
		INFO_DIR=${D}/usr/share/info EMACS_SITE_LISP=${D}/usr/share/emacs/site-lisp/gcl \
		EMACS_DEFAULT_EL=${D}/usr/share/emacs/site-lisp/gcl/default.el \
		|| die

	rm -f ${D}/usr/share/infodir

	mv ${D}/usr/lib/${P}/info/* ${D}/usr/share/info
	rm ${D}/usr/share/info/texinfo.tex
	rm ${D}/usr/share/emacs/site-lisp/gcl/default.el

	mv ${D}/usr/bin/gcl ${D}/usr/bin/gcl.orig
	sed -e "s:${D}::g" < ${D}/usr/bin/gcl.orig > ${D}/usr/bin/gcl
	rm ${D}/usr/bin/gcl.orig

	# fix the GCL_TK_DIR=/var/tmp/portage/gcl-2.4.3/image//
	mv ${D}/usr/lib/gcl-2.5.0/gcl-tk/gcltksrv
${D}/usr/lib/gcl-2.5.0/gcl-tk/gcltksrv.orig
	sed -e "s:${D}::g" < ${D}/usr/lib/gcl-2.5.0/gcl-tk/gcltksrv.orig >
${D}/usr/lib/gcl-2.5.0/gcl-tk/gcltksrv
	rm ${D}/usr/lib/gcl-2.5.0/gcl-tk/gcltksrv.orig
	chmod 0755 ${D}/usr/lib/gcl-2.5.0/gcl-tk/gcltksrv

	chmod 0755 ${D}/usr/bin/gcl

	#repair gcl.exe symlink
	rm ${D}/usr/bin/gcl.exe
	dosym ../lib/gcl-2.5.0/unixport/saved_gcl /usr/bin/gcl.exe
}


Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Hi Cliff.

Thanks a lot for your submission!
Could you please attach ebuild to the bug? I would rather not risk copying it out, as this quite often causes problems (and decreases readability of the bugs).

George

Created an attachment (id=11066) [edit]
Ebuild for gcl 2.5.2

Hi Cliff.

Thanks for attachment.
I have processed and committed the ebuild. Please test, so that I can move it to stable profile, to resolve the problems with bfd libraries.

A short note:
Please do not spell out gcl-2.5.0, use ${P} (and ${PN}, ${PV}) construct[s] instead where appropriate. Apparently that confused even you - there were few broken paths which I had to clean-up.

George

Opps :-).  Sorry about that.  I think I just left that part in from the 2.4.3
one, but I'm not sure - I tried to do a minimal change set because I didn't
know what I would be breaking if I changed too much.

Emerged using the new ebuild from the tree, and it worked like a charm :-). 
I'd say go ahead and add it to stable - it can't be any less functional than
the ones there now ;-).

Just out of curosity, is there a flag I can add to emerge --pretend world so it
won't try to downgrade stuff?  Ususally if I have upgraded beyond stable there
is a good reason (For example, I used the 2.6 ebuild of scilab to install 2.7
by just changing the numbers, and now it keeps wanting to downgrade it.) 

reclosing the bug