Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 192761 - sci-electronics/ghdl - bad mtimes of library files
Summary: sci-electronics/ghdl - bad mtimes of library files
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: The Soldering-Iron Brotherhood
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-17 03:28 UTC by Jonathan Geisler
Modified: 2011-05-14 14:34 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
first try to fix the problem - NOT WORKING (ghdl-0.26.ebuild_time.patch,892 bytes, patch)
2008-05-18 18:57 UTC, Markus Rothe (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Geisler 2007-09-17 03:28:16 UTC
GHDL installs library files that check their mtimes.  See bug #83877 for all the info during the ebuild development.  For some reason, the committed ebuild doesn't solve the problem that the old pkg_postinst() function was working around.  This means that using the common libraries (e.g., IEEE) causes the compiler to abort.  The workaround is to reanalyze the libraries in your working directory so that the mtimes are fine.

Reproducible: Always

Steps to Reproduce:
1. Create the following file named empty.vhdl:

LIBRARY ieee;
USE ieee.std_logic_1164.all

ENTITY empty IS
END empty;

2. ghdl -a empty.vhdl

Actual Results:  
JGG.vhdl:2:10: file ../../../src/ieee/std_logic_1164.v93 has changed and must be reanalysed
JGG.vhdl:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gna.org/projects/ghdl> for instructions.
ghdl: compilation error

******************** GHDL Bug occured ****************************
Please report this bug on http://gna.org/projects/ghdl
GHDL release: GHDL 0.26 (20070408) [Sokcho edition]
Compiled with GNAT Version: 4.2.0
In directory: /home/jgeisler/classes/cos381/vhdl/
Command line:
ghdl -a JGG.vhdl
Exception STORAGE_ERROR raised
Exception information:
Exception name: STORAGE_ERROR
Message: stack overflow (or erroneous memory access)
Call stack traceback locations:
0x8111cd6 0x8136e3b
******************************************************************


Expected Results:  
The program should have compiled without any errors.
Comment 1 Denis Dupeyron (RETIRED) gentoo-dev 2007-10-11 13:09:01 UTC
(In reply to comment #0)
> GHDL installs library files that check their mtimes.  See bug #83877 for all
> the info during the ebuild development.  For some reason, the committed ebuild
> doesn't solve the problem that the old pkg_postinst() function was working
> around.  This means that using the common libraries (e.g., IEEE) causes the
> compiler to abort.  The workaround is to reanalyze the libraries in your
> working directory so that the mtimes are fine.

The reason why the workaround wasn't implemented is that it is simply not allowed to touch installed files in pkg_postinst(). If you do so, it is impossible to have then automatically removed or updated by a later emerge. Sorry if this wasn't clear enough in the original bug.

> Steps to Reproduce:
> 1. Create the following file named empty.vhdl:
> 
> LIBRARY ieee;
> USE ieee.std_logic_1164.all
> 
> ENTITY empty IS
> END empty;
> 
> 2. ghdl -a empty.vhdl

This works correctly for me (after adding a semi-column at the end of the USE line, though). I'm sorry to hear it doesn't for you, but I suspect it may be due to you having used the old ebuild and old files still being present on your system.

I'm closing this bug WORKSFORME. You can reopen it when you have cleaned up everything, successfully emerged ghdl with FEATURES=collision-protect and you're sure your sandbox setup is correct. In which case I will need the result of an 'emerge --info' at the very least.

Denis.
Comment 2 Jonathan Geisler 2007-10-11 15:16:42 UTC
This is the only time I've merged ghdl, so it is not a situation of conflicting with previous installs.  I can also confirm several of my students getting the same problem when installing ghdl on their Gentoo systems.

The reasoning from the previous bug made sense to me, I just expected the solution to exist in some other format and it didn't get solved for me, and so that is why I referenced it.

Here is my emerge --info file:

Portage 2.1.3.9 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.5-r4, 2.6.22-gentoo-r5 i686)
=================================================================
System uname: 2.6.22-gentoo-r5 i686 Genuine Intel(R) CPU T2500 @ 2.00GHz
Timestamp of tree: Wed, 10 Oct 2007 14:20:01 +0000
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.4-r5
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17-r1
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.22-r2
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="candy distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://mirror.mcs.anl.gov/pub/gentoo/ ftp://gentoo.cites.uiuc.edu/pub/gentoo/ http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LINGUAS="en_US"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="X acpi alsa apache2 arts berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups dbus doc dri dvd dvdr eds emboss encode esd fam firefox fortran gdbm gif gnome gpm gstreamer gtk gtk2 hal iconv ipv6 isdnlog java jpeg kde ldap mad mbox midi mikmod mmx mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin ogg opengl openmp oss pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl tcpd tetex threads truetype truetype-fonts type1-fonts unicode usb vorbis win32codecs x86 xcb xinerama xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_US" USERLAND="GNU" VIDEO_CARDS="dummy fglrx"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Let me know if you need any other output from the system
Comment 3 Denis Dupeyron (RETIRED) gentoo-dev 2007-10-11 15:46:07 UTC
Zac,

Since you're the one who was nice enough to add this to portage, do you have any idea of what can go wrong here ?

Thanks in advance.
Comment 4 Zac Medico gentoo-dev 2007-10-11 17:16:17 UTC
The merge process should preserve file timestamps from ${D}. However, perhaps your timestamps are modified during src_install() when the files are copied to ${D}. For example, the default install(1) options used by do* helper scripts are defined in /usr/lib/portage/bin/ebuild.sh:

export INSOPTIONS="-m0644"
export EXEOPTIONS="-m0755"
export LIBOPTIONS="-m0644"
export DIROPTIONS="-m0755"

It's possible for the ebuild to use the insopts(), diropts(), exeopts(), and libopts() helper functions to set those variables to preserve timestamps by doing something like this:

insopts -m0644 -p
exeopts -m0755 -p
libopts -m0644 -p
diropts -m0755 -p

Those functions appear to be undocumented in the ebuild(5) manual page, but it's OK to use them since they are documented in PMS and some ebuilds in the tree are using them.
Comment 5 Markus Rothe (RETIRED) gentoo-dev 2008-05-18 18:57:18 UTC
Created attachment 153581 [details, diff]
first try to fix the problem - NOT WORKING

I have a whole lot of trouble fixing this problem. The attached patch replaces the options of the "/usr/bin/install" command in the configure script. Else the timestamps get altered for the first time when running make install. (Could someone please confirm this? and why do other people do not suffer from this, when they use the stock configure script)

Unfortunately even with the -p option used with /usr/bin/install the timestamps are not equal:

# pwd
/var/tmp/paludis/sci-electronics-ghdl-0.26
# find . -name textio.v93 -exec ls -l --full-time {} \;
-rw-r--r-- 1 root paludisbuild 5351 2008-05-18 20:17:40.616394639 +0200 ./work/gcc-4.1.2/gcc/vhdl/libraries/std/textio.v93
-rw-r--r-- 1 root paludisbuild 5351 2008-05-18 20:17:40.616394000 +0200 ./image/usr/lib/gcc/powerpc-unknown-linux-gnu/4.1.2/vhdl/src/std/textio.v93

and the timestamp in image/ also differs from the timestamp in ${root}:

# ls -l --full-time /usr/lib/gcc/powerpc-unknown-linux-gnu/4.1.2/vhdl/src/std/textio.v93
-rw-r--r-- 1 root root 5351 2008-05-18 20:19:38.052007270 +0200 /usr/lib/gcc/powerpc-unknown-linux-gnu/4.1.2/vhdl/src/std/textio.v93


Seems like paludis does not respect insopts etc.? I'll check that with paludis people or try to get the package compiled with portage on another machine.

I would really like to try out ghdl! Please, someone help me fixing this :-)
Comment 6 Zac Medico gentoo-dev 2008-05-18 19:14:39 UTC
(In reply to comment #5)
> Seems like paludis does not respect insopts etc.? I'll check that with paludis
> people or try to get the package compiled with portage on another machine.

One plausible explanation is that paludis bumps timestamps during the merge process, just as <portage-2.1.3 used to.
Comment 7 Markus Rothe (RETIRED) gentoo-dev 2008-05-18 19:51:47 UTC
yes, I asked in #paludis and paludis doesn't "preserve mtimes for the final merge".

common-lisp.eclass has a hack for preserving mtime. I'll take a look at that.

Another option would be to regenerate the files in a post_install.

This laptop is too slow for yet another trail&error compile of this package. I'll try to find some time next week to look into this problem again - on a faster machine then..
Comment 8 Denis Dupeyron (RETIRED) gentoo-dev 2008-05-18 20:28:55 UTC
(In reply to comment #7)
> Another option would be to regenerate the files in a post_install.

Not an option, since AFAIK you wouldn't be able to uninstall or update after that. This was the whole point of bug #83877 and Zac changing Portage in version 2.1.3.

Denis.
Comment 9 Markus Rothe (RETIRED) gentoo-dev 2008-07-27 16:19:54 UTC
ghdl 0.27 (not yet in portage - change GCC_VERSION from 4.1.2 to 4.2.4 in the ebuild) builds and works if I use portage instead of paludis. There were no patches to the ebuild or ghdl needed. I haven't tried 0.26 with portage (only paludis, which does not work).
Comment 10 Justin Lecher (RETIRED) gentoo-dev 2010-06-23 07:50:03 UTC
Is this fixed for current versions?
Comment 11 Thomas Beierlein gentoo-dev 2010-07-08 08:41:38 UTC
(In reply to comment #10)
> Is this fixed for current versions?
> 

Tested it on ghdl-0.29 for amd64 as well as for x86 using portage without the problem (gcc-4.4.3-r2).

Former problems seems only to be related to paludis. So maybe someone should test it with that pm too.
Comment 12 fatty 2010-07-29 17:19:04 UTC
I've installed version 0.29 yesterday with paludis. Unfortunately the problem still exists here.
Comment 13 Thomas Beierlein gentoo-dev 2011-05-14 14:34:17 UTC
EAPI=3 preserves timestamps. Fixes the problem for me.

+  14 May 2011; Thomas Beierlein <tomjbe@gentoo.org> ghdl-0.29.ebuild:
+  Switch to EAPI=3 to fix bug #192761
+