Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Attached is an ebuild and patches for the ghdl VHDL compiler/simulator. It uses GCC as its backend and requires the gnat ADA compiler to build the source. Waveforms may be viewed with gtkwave and eventually ivi. ghdl may be used to perform hardware simulation/development. I maintain this package in my local 'sci-electronics'. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created an attachment (id=52490) [edit] ghdl-0.17.ebuild ghdl-0.17.ebuild
Created an attachment (id=52491) [edit] gcc patch
Created an attachment (id=52492) [edit] ghdl source patch
Updated ebuild and summary for new ghdl release
please bring this to the official portage-tree!
This ebuild installs stuff in pkg_postinst which is definitely no good idea (since these files will not be uninstalled/checked/whatever by portage).
The comment regarding pkg_postinst is noted. The purpose for the hack is that ghdl builds data files during src_compile that have a timestamp contained within the file. When the data files are merged into the system ghdl compares the timestamp within the file to the mtime, notes the difference and says the libraries need to be freshened, and exits. Can you provide a suggestion or another workaround to this other than installing in pkg_postinst? If this is all that's holding up the ebuild, I'm willing to implement a suggestion.
Created an attachment (id=60161) [edit] updated ebuild new ebuild that no longer performs an install in pkg_postinst, instead it calls ghdl on the freshly emerged libraries and updates them in place. Is ghdl closer to being accepted now?
Created an attachment (id=60213) [edit] ghdl-0.18-r2.ebuild works with <=dev-lang/gnat-3.15p-r5
Created an attachment (id=69193) [edit] ghdl-0.19.ebuild This is a update to matt's ebuild but with a fix so that the mentor and synopsys libraries are also updated in the postinst step. Works great for me otherwise.
I very much appreciate this ebuild. However sitting on a plain new gentoo system, gnat-3.15p-r5 failed to build for me. (see bug 119296 for this) I changed the depend to read "dev-lang/gnat" and now it works using gnat-3.45 Matt, would you like to change the ebuild? To the sci herd: what is blocking this from entering the official tree? I'm quite interested to bring it in. Please state what needs to be resolved.
(In reply to comment #11) > To the sci herd: what is blocking this from entering the official tree? I'm > quite interested to bring it in. Please state what needs to be resolved. Mostly the maintainership problem. At present sci herd has over 200 bugs open, of which only about 35 are of normal or higher severity (and the rest are enhancement - new packages mostly). And we already have ~200 packages in >10 different categories belonging to sci. And we are only ~10 people. This is just to illustrate the shortage of manpower. Essentially the major requirement for it to go in is for somebody to be willing to maintain it. This means either an existing developer personally interested in the package or a user willing to become a developer and help out in Scientific Gentoo.. George
(In reply to comment #11) > Matt, would you like to change the ebuild? you may make the change to the ebuild. I took your change and it won't compile for me and i need just a bit more time to debug. However, I'm trying to run an amd64 system now, and i have stable versions of gcc/binutils/libtool installed - I wonder if that's the difference. what versions of binutils and gcc do you have installed? can you post `emerge --info`? did you upgrade the gcc that's downloaded as part of the ebuild in your version? currently it's set to 3.4.3, which is I guess, old. (In reply to comment #12) > Essentially the major requirement for it to go in is for somebody to be willing > to maintain it. This means either an existing developer personally interested > in the package or a user willing to become a developer and help out in > Scientific Gentoo.. I don't mind maintaining this ebuild if noone else has time, so I wouldn't mind becoming a developer to maintain it and/or other sci-electronic applications. Hopefully, we can have ~amd64 added to the platforms soon.
Hi Matt. Please take a look here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2 What you need to do is to apply for being a developer. Email recruiters@gentoo.org and CC sci@gentoo.org. It would be nice to have somebody agree to mentor you prior to that and I could do that normally, but I am mentoring one person at the moment, is going to take up another one and I will be gone most of February. So, this time is not good for me. However you can try sending an email to gentoo-science@lists.gentoo.org - this is a Scientific Gentoo mailing list, asking if somebody would be willing to take you up. I believe you will need to subscribe to post on it, but you will have to do that anyway as a sci developer (and it is a rather low traffic). The sci alias will propagate this message anyway, but there are more people on that mailing list than on sci alias. You may send an application (to recruiters@ CC sci@) as I mentioned above anyway, however it will most likely be put on hold, until the mentor is found anyway, so it is best to take active steps yourself. If all falls short I'll see to this when I return, but hopefully somebody from a sci team will take you up. George
On the ebuild (0.19). I see there is a lengthy pkg_postinst function that sets up bunch of vars and then performs a cycle of compilations. What is the purpose of these ghdl calls? Why cannot they be made during src_compile or src_install (1st one is preferable)? The normal policy is to not do modifications to the installed package in pkg_postinst, as this will screw unmerge - files installed in this way or their modifications are not registered. Then, during unmerge, portage thinks they do not belong to the package or something external modified them and thus does not remove them. Is there a problem with hardcoded paths? Usually it is better to sed them out or (even better) fix the build scripts (Makefiles, etc). The main purpose of pkg_postinst is to setup the environment in a proper way (such as run eselect) and do user notifications.. George
Created an attachment (id=77954) [edit] ghdl-0.19 ebuild uses the latest gnat in portage.
(In reply to comment #15) > On the ebuild (0.19). > > I see there is a lengthy pkg_postinst function that sets up bunch of vars and > then performs a cycle of compilations. What is the purpose of these ghdl calls? > Why cannot they be made during src_compile or src_install (1st one is > preferable)? [...] > George George, Thank you for your feedback. During src_compile, this package creates a set of data files (it's seems to be a type of system library archive) that have timestamps associated with .vhdl files recorded within the file. When the files are installed during src_install, the timestamps in the data files no longer correspond to the actual mtime of the files being installed. When the ghdl compiler looks at these system library .vhdl files and notes the discrepancy, the ghdl compiler aborts. The pkg_postinst step was definitely a hack to work around this behavior and just build the data files in place. I know it's less than optimal, and would appreciate feedback about a way to resolve it.
hmmm, I've just tried installing the latest ghdl-0.19-r1 and have run into a problem. everything was working sweet with the old rev. now when I build and try to run the hello_world example I get the following message: /usr/lib/ghdl/gcc/i686-pc-linux-gnu/3.4.3/vhdl/lib//libgrt.a(grt-cvpi.o): In function `module_open': grt/grt-cvpi.c:160: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Any ideas what to do here?
Created an attachment (id=78049) [edit] Broken ghdl-0.21 ebuild In an effort to get the latest and greatest I've tried to get ghdl-0.21 to work. The attached ebuild builds the compiler and installs ok. But trying to build and run a vhdl programresults in the following error message: [LD] hello.o /usr/lib/ghdl/gcc/i686-pc-linux-gnu/4.0.2/vhdl/lib//libgrt.a(run-bind.o): In function `grt_init': run-bind.o:(.text+0x9): undefined reference to `ada__exceptions_E' run-bind.o:(.text+0x14): undefined reference to `ada__exceptions___elabs' run-bind.o:(.text+0x1b): undefined reference to `system__exceptions_E' run-bind.o:(.text+0x26): undefined reference to `system__exceptions___elabs' run-bind.o:(.text+0x2c): undefined reference to `system__exceptions_E' run-bind.o:(.text+0x34): undefined reference to `system__soft_links_E' run-bind.o:(.text+0x3f): undefined reference to `system__soft_links___elabb' run-bind.o:(.text+0x45): undefined reference to `system__soft_links_E' run-bind.o:(.text+0x4d): undefined reference to `system__secondary_stack_E' run-bind.o:(.text+0x58): undefined reference to `system__secondary_stack___elabb' run-bind.o:(.text+0x5e): undefined reference to `system__secondary_stack_E' run-bind.o:(.text+0x66): undefined reference to `system__exception_table_E' run-bind.o:(.text+0x71): undefined reference to `system__exception_table___elabb' run-bind.o:(.text+0x77): undefined reference to `system__exception_table_E' run-bind.o:(.text+0x7f): undefined reference to `ada__exceptions_E' run-bind.o:(.text+0x8a): undefined reference to `ada__exceptions___elabb' run-bind.o:(.text+0x90): undefined reference to `ada__exceptions_E' collect2: ld returned 1 exit status ghdl: compilation error Anyone got any ideas?
Created an attachment (id=78050) [edit] Patch file for gcc-4.0.2 for ghdl-0.21 patch need to be updated to build with ghdl-0.21
(From update of attachment 78049 [edit]) this ebuild seems to be fine. bugs are actually in the ghdl source. updated patch kinda fixes things.
Created an attachment (id=78144) [edit] updated patch for 0.21 With this latest patch I can emerge ghdl-0.21 and build and run code with gnat-3.45. There is still one outstandng issue with the following warning during linking the vhdl apps. /usr/lib/ghdl/gcc/i686-pc-linux-gnu/4.0.2/vhdl/lib//libgrt.a(grt-cvpi.o): In function `module_open': /var/tmp/portage/ghdl-0.21/work/gcc-4.0.2/gcc/vhdl/grt/grt-cvpi.c:175: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
Created an attachment (id=81748) [edit] ghdl-0.21 cross-platform ebuild GHDL appears to work well on PPC. A set of various VHDL testbenches simulate identically with GHDL v0.21 on i686 (pentium4) and PPC (G4 7450). ghdl-0.21-r1.ebuild fixes the compiler location to use CHOST rather than hardcoded to i686, and adds ~ppc to keywords.
A set of various VHDL testbenches simulate identically with GHDL v0.21 on i686 (pentium4) and PPC (G4 7450). For i686, used gnat-3.45. Successful simulations with complex configurations. For PPC, used gnat-3.43. Successful simulations with complex configurations. NOTE: Dependency should be specifically GNAT >= 3.4* . No versions compile on PPC with GNAT = 3.15*. I anticipate same for x86. Note that GNAT >= 3.4 has non-testing ebuilds on x86, but not PPC and other platforms. Anyone going to check this ebuild into the gentooscience overlay which we wait on the official portage tree?
Created an attachment (id=83267) [edit] Another custum ebuild for GHDL 0.21 (some code clean-up, added misc explanations) It has some improvements, IMHO. Especially about to support multilib profile archs. But, I have no test on amd64 or so because of I have no 64bit gentoo...
Created an attachment (id=90413) [edit] a ebuild for ghdl-0.2.4 version bump to 0.24 this version has some bug fixes and GHDL's man-page.
the ebuild on the above required ghdl-0.23.patch. it's Joe's patch for ghdl-0.21 in this bug report.
Very interesting work here. The only thing blocking me from including this into Portage (besides cleanups, but that's easy), is the reanalyzing of the libs in pkg_postinst(). This has to be done in src_compile() or src_install() instead. I understand it's not an easy thing to do. If anybody wants to tackle this, I'm offering to help him/her with it. If it's a long and/or complicated question, for example, do not hesitate to contact me directly by email instead of on this bug. I'm also usually available on the gentoo irc channels (/query me directly to wake me up). Denis.
(From update of attachment 90413 [edit]) fix silly typo (0.2.4 -> 0.24)
FYI, 0.25 was released, it has sevral bug fixes or so. For more detail, see its Homepage/ML announce or so. In my case, simply renaming previous version's ebuild may be OK. And then, to remove remaining craps are recommended, but it's manually, ATM. calchan: I know these ebuilds (even if it's mine) are not enough to release as offcial one. Because of remaining crappy object files or so even if it was unmerged. But it's normal VHDL analyse behavior, isn't it? So, 2 ways are, IMHO. (1) Detect its craps if older version was installed, then abort emerge process and notify the users manually removing is required. (2) Detect its craps if older version was installed, then automatically removing inside emerge process. I think (2) is better. Thus I mean, "Is there ebuild which uses method of (2)?" I've seen a ebuild which uses method of (1). (It's maybe xkbdata stuff, but not sure, just forgort, though.) If good samples are, please let me know for sane fixing...
We should change the ghdl ebuild to depend upon one of several gnat compilers. GHDL 0.21 compiled and works just fine with ~dev-lang/gnat-gcc-3.4.6 (tested on x86 w/ Pentium4 CFLAGS). Now that profile 2006.1 uses gcc-4*, it is troublesome at best to install dev-lang/gnat which directly depends upon gcc-3* , whereas dev-lang/gnat-gcc will compile mostly independent of the active gcc version. Change the ebuild's dependency line to: DEPEND=" ( || ( dev-lang/gnat dev-lang/gnat-gcc ) )" We could use the virtual for gnat dependencies, but it seems best not too as the virtual's slots are incorrect and does not consider dev-lang/gnat .
Created an attachment (id=98144) [edit] ghdl-0.25-r1.ebuild.diff I tried ghdl-0.25 w/ dev-lang/gnat-gcc-4.1.1 on my ~ppc env. ATM, virtual/gnat-4.1 has no ~ppc keyword, but it works for me. Attached diff is for ghdl-0.25 w/ virtual/gnat-4.1. I just renamed my own previous version's ghdl ebuild (was filed as ghdl-0.24.ebuild here) to ghdl-0.25.ebuild. It can be applyed for -r1 rev-bump. Timothy: Thanks contributing new gnat for ppc, bug #130509, BTW. :)
Sorry, just noticed this package. Will throw a few quick comments right now and then see if I can process it - since I am in both ada and sci I should be "qualified" to do this better than anybody else :). However if electronics people want to track this themselves, please say so, I'll only post test reports and updates then. (In reply to comment #31) > Now that profile 2006.1 uses gcc-4*, it is troublesome at best to install > dev-lang/gnat which directly depends upon gcc-3* , whereas dev-lang/gnat-gcc > will compile mostly independent of the active gcc version. This is correct, however the real situation is even "stronger": > Change the ebuild's dependency line to: > DEPEND=" ( || ( dev-lang/gnat dev-lang/gnat-gcc ) )" This is really bad. dev-lang/gnat is a "legacy" package and is masked and will be removed soon. It breaks heavily on many systems, requires old binutils and does not do a good job wrt multilib. On top of that it was reported to collide with gcc in some situations (very bad). That is, this package is really deprecated and everybody still having it is strongly advised to use gnat-gcc or gnat-gpl. gnat-gcc has both 3.4 and 4.1 backend versions while gnat-gpl is based on gcc-3.4 (that's ACT's gnat, they did not issue gcc-4 based release yet), all properly slotted. So, that above line should be simply virtual/gnat. If you want to control what version of gnat will be used simply emerge it explicitly, then virtual/gnat will pick it up and be happy. I'll try to take a look at the ebuild soon to see if any other changes are necessary. > > We could use the virtual for gnat dependencies, but it seems best not too as > the virtual's slots are incorrect and does not consider dev-lang/gnat . Virtual should be fine now, are there any problems still? If there are, please report them in a new bug, assigning to ada@g.o directly. George
(In reply to comment #33) > "qualified" to do this better than anybody else :). However if electronics > people want to track this themselves, please say so, I'll only post test > reports and updates then. Unfortunately "electronics people" is just me alone right now, and I just came back yesterday. So I would very much like help about this package (which I think is an interesting one to have), especially concerning the ada aspect. I still believe this ebuild is not ready for inclusion in portage as it is today. For example, there is the matter detailed in comment #28 which is right now a definite no-go. This comment was also a not-so-hidden bait to recruit a new dev or proxy-dev, but it seems it didn't work out. The ebuild also needs a lot of polishing and cleanup, but that is easy. I still have a lot of mess to clean up since I just came back, but this one is still definitely on my radar. However that should not prevent you from having a look at it ;o) especially the ada stuff. Maybe we should talk about this on irc. Denis.
There is ghdl-0.26 released upstream. If i find the time next week, i will take a look at it.
Here's a short update on my progress. I have good news, then bad news and then good news. First I have found where the timestamps were and could change the mtime of the corresponding files in pkg_postinst. I knew in advance that it would work for ghdl but not for portage, as files with an mtime different from when they were installed cannot be uninstalled. My second idea was to change the timestamps to whatever the mtimes were, and then change the mtimes of the timestamp files to what they were before I changed the timestamps (still following me ?) in order to cover my tracks. It didn't work either because the md5 of the timestamp files changed. I should have guessed this one. My third idea I don't dare say it for fear of being decapitated in public (it involved touching files in /var/db/pkg from within the ebuild). ;o) So I had a nice chat on irc with Zac Medico about this, and the conclusion was that Portage was the culprit. He has an idea of what to do and offered to work on a patch. Denis.
Hi all, A quick update. Zac Medico has committed a new version of portage which helps in the case of ghdl. Unfortunately there seems to be an issue with it (see bug #181387). I have no doubt that Zac will fix it though, and when he does so I'll commit an ebuild for ghdl-0.26 that I have successfully tested locally (I ran the example of the DLX processor). Denis.
FYI, I've just read this obvious fix[1] via ML. So, we should apply this patch I thought. Personally, I have not used this complex lib in my VHDL though. :P --- [1] https://mail.gna.org/public/ghdl-discuss/2007-06/msg00000.html
Just a note that two libraries were missing from the 0.26 ebuild `reanalyze_libs' function when I last downloaded it (months ago). Whoever feels like double-checking, please do so. Thanks. --- +++ local IEEE93SRCS="src/ieee/std_logic_1164.v93 \ src/ieee/std_logic_1164_body.v93 \ src/ieee/numeric_bit.v93 \ src/ieee/numeric_bit-body.v93 \ src/ieee/numeric_std.v93 \ src/ieee/numeric_std-body.v93 \ + src/ieee/math_real.vhdl \ + src/ieee/math_real-body.vhdl \ src/vital2000/timing_p.vhdl \ src/vital2000/timing_b.vhdl \ src/vital2000/prmtvs_p.vhdl \ src/vital2000/prmtvs_b.vhdl \ src/vital2000/memory_p.vhdl \ src/vital2000/memory_b.vhdl"
Hmm... some mal-formating with the last post. Variable `IEEE93SRCS' needs to additionally contain: 'src/ieee/math_real.vhdl' and 'src/ieee/math_real-body.vhdl'.
Timothy, do not worry about reanalyzing the libraries as it wont be needed in the final ebuild. Masaru, thanks for the link. I'll get my calculus ruler and will check this formula. ;o) Denis.
FYI, I've updated the ebuild for 0.26 just for a testing. And polishing up something like, * trimming redundant einfo and \ escapes * fix some typos in comments * patch for atan2 in math_complex * add missing math_{real,complex} sources in reanalyze_libs Still now, I'm not sure whether it's commit-ready quality though. But it can be available from my misc overlay[1]. Denis: bug #181387 is already closed, so time to do it now? :9 Timothy: Thanks to poke my stupid mistake, BTW. :) --- [1] http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi
(In reply to comment #42) > bug #181387 is already closed, so time to do it now? :9 It's now in CVS and will start reaching mirrors soon. I have keyworded it ~x86 only as it's the only architecture I can test it on. If you test it successfully on any other architecture feel free to send me an mail directly (no need to open a bug). Please make sure you have tested it thoroughly enough though (at least running the dlx example as described in the GHDL doc for instance). I'm now closing this bug. If you encounter any issue you should open a new bug. Thanks to everybody for your contribution. Denis.
