There's a new upstream version of tcc; now with autoconf. Reproducible: Always Steps to Reproduce:
Created attachment 12206 [details] tcc-0.9.18.ebuild
Hi Thomas. Thanks for submission! I am processing it, and it looks ok except one thing. After running ebuild tcc-0.9.18.ebuild fetch unpack compile install and checking the installation I see the following under ${D}/usr: groug usr # pwd /var/tmp/portage/tcc-0.9.18/image/usr groug usr # ls -F bin/ include lib/ share/ As you see ^^ include is a file (which actually contains some definitions), while this is supposed to be a dir. If I remove "includedir=${D}/usr/include \" line from src_install it tries to install libtcc.h under /usr/include... So, it seems that autoconf stuff is broken in this package (at least it misuses includedir option from what I see). Can you please confirm? If this is indeed the case the fix seems to be quite trivial in ebuild - just dodir /usr/include and rename this file appropriately (actually you'll need to move it around first to avoid naming conflict). George
Hi George, confirmed -- the "libinstall"-target does not care if directories exist or not; and I overlooked /usr/include :( The dodir-fix worked for me (just adding a "dodir /usr/include" around line 30); no need to move files around or something like that. autoconf is not generally broken in the package -- but it does not create the needed target-directories if they are missing. If I had used "includedir=${D}/usr/include/" (note the trailing "/") this wouldn't have happend. I suggest adding a "/" to all directories mentioned in src_install as an install-target, too. Thomas
On May 24 a new version was released (v0.9.19). Just renaming the ebuild did work for me (the configure-script behaves not better, so the directories still need to be created "by hand" -- including /usr/include). Thomas
Hi Thomas. Thanks for the notice! The changed did work so I committed the ebuild for new version. Please test. George
Hi George, looks OK for me -- tested with gcc 2.95.3 (still on a 1.0 profile ;) Thanks for the quick respone, Thomas
I think this is a stale bug now -- 0.9.19 is in portage and unmasked. So I'm trying to close it now.