Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 83877 - ghdl-0.25-r1.ebuild (New Package)
Summary: ghdl-0.25-r1.ebuild (New Package)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: The Soldering-Iron Brotherhood
URL: http://ghdl.free.fr
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-02 13:31 UTC by matt
Modified: 2007-06-29 21:23 UTC (History)
8 users (show)

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


Attachments
ghdl-0.18.ebuild (ghdl-0.18.ebuild,1.94 KB, text/plain)
2005-03-02 13:33 UTC, matt
Details
gcc patch (gccpatch,1.66 KB, patch)
2005-03-02 13:34 UTC, matt
Details | Diff
ghdl source patch (ghdlpatch,606 bytes, patch)
2005-03-02 13:34 UTC, matt
Details | Diff
ghdl-0.18-r1.ebuild (ghdl-0.18-r1.ebuild,4.35 KB, text/plain)
2005-05-29 23:34 UTC, matt
Details
ghdl-0.18-r2.ebuild (ghdl-0.18-r2.ebuild,4.31 KB, text/plain)
2005-05-30 13:37 UTC, matt
Details
ghdl-0.19.ebuild (ghdl-0.19.ebuild,4.49 KB, text/plain)
2005-09-25 00:26 UTC, Joe
Details
ghdl-0.19-r1 ebuild (ghdl-0.19-r1.ebuild,4.48 KB, text/plain)
2006-01-23 14:16 UTC, matt
Details
ghdl-0.21 ebuild (ghdl-0.21.ebuild,4.54 KB, text/plain)
2006-01-24 22:50 UTC, Joe
Details
Patch file for gcc-4.0.2 for ghdl-0.21 (ghdlpatch-0.21,625 bytes, text/plain)
2006-01-24 22:51 UTC, Joe
Details
updated patch for 0.21 (ghdlpatch-0.21,863 bytes, patch)
2006-01-26 02:39 UTC, Joe
Details | Diff
ghdl-0.21 cross-platform ebuild (ghdl-0.21-r1.ebuild,4.53 KB, text/plain)
2006-03-09 02:04 UTC, Timothy Stotts
Details
Another custum ebuild for GHDL 0.21 (some code clean-up, added misc explanations) (ghdl-0.21-r1.ebuild,9.94 KB, text/plain)
2006-03-27 15:08 UTC, hiyuh
Details
a ebuild for ghdl-0.24 (ghdl-0.24.ebuild,10.01 KB, text/plain)
2006-06-29 04:17 UTC, hiyuh
Details
ghdl-0.25-r1.ebuild.diff (ghdl-0.25-r1.ebuild.diff,997 bytes, patch)
2006-09-26 10:13 UTC, hiyuh
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description matt 2005-03-02 13:31:43 UTC
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.
Comment 1 matt 2005-03-02 13:33:14 UTC
Created attachment 52490 [details]
ghdl-0.18.ebuild

ghdl-0.17.ebuild
Comment 2 matt 2005-03-02 13:34:05 UTC
Created attachment 52491 [details, diff]
gcc patch
Comment 3 matt 2005-03-02 13:34:26 UTC
Created attachment 52492 [details, diff]
ghdl source patch
Comment 4 matt 2005-03-12 08:01:32 UTC
Updated ebuild and summary for new ghdl release
Comment 5 Michael Gaber 2005-05-25 01:49:24 UTC
please bring this to the official portage-tree!
Comment 6 Patrick Kursawe (RETIRED) gentoo-dev 2005-05-25 04:29:40 UTC
This ebuild installs stuff in pkg_postinst which is definitely no good idea
(since these files will not be uninstalled/checked/whatever by portage).
Comment 7 matt 2005-05-25 08:28:19 UTC
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.
Comment 8 matt 2005-05-29 23:34:51 UTC
Created attachment 60161 [details]
ghdl-0.18-r1.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?
Comment 9 matt 2005-05-30 13:37:15 UTC
Created attachment 60213 [details]
ghdl-0.18-r2.ebuild

works with <=dev-lang/gnat-3.15p-r5
Comment 10 Joe 2005-09-25 00:26:35 UTC
Created attachment 69193 [details]
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.
Comment 11 Matti Bickel (RETIRED) gentoo-dev 2006-01-17 11:22:29 UTC
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.
Comment 12 George Shapovalov (RETIRED) gentoo-dev 2006-01-17 13:16:02 UTC
(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
Comment 13 matt 2006-01-17 20:37:58 UTC
(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.
Comment 14 George Shapovalov (RETIRED) gentoo-dev 2006-01-19 04:55:14 UTC
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
Comment 15 George Shapovalov (RETIRED) gentoo-dev 2006-01-19 05:06:03 UTC
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
Comment 16 matt 2006-01-23 14:16:29 UTC
Created attachment 77954 [details]
ghdl-0.19-r1 ebuild

uses the latest gnat in portage.
Comment 17 matt 2006-01-23 14:31:09 UTC
(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.
Comment 18 Joe 2006-01-24 22:46:21 UTC
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?
Comment 19 Joe 2006-01-24 22:50:42 UTC
Created attachment 78049 [details]
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?
Comment 20 Joe 2006-01-24 22:51:55 UTC
Created attachment 78050 [details]
Patch file for gcc-4.0.2 for ghdl-0.21

patch need to be updated to build with ghdl-0.21
Comment 21 Joe 2006-01-26 02:34:49 UTC
Comment on attachment 78049 [details]
ghdl-0.21 ebuild

this ebuild seems to be fine. bugs are actually in the ghdl source. updated patch kinda fixes things.
Comment 22 Joe 2006-01-26 02:39:07 UTC
Created attachment 78144 [details, diff]
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
Comment 23 Timothy Stotts 2006-03-09 02:04:29 UTC
Created attachment 81748 [details]
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.
Comment 24 Timothy Stotts 2006-03-09 02:05:38 UTC
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?

Comment 25 hiyuh 2006-03-27 15:08:00 UTC
Created attachment 83267 [details]
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...
Comment 26 hiyuh 2006-06-29 04:17:35 UTC
Created attachment 90413 [details]
a ebuild for ghdl-0.24

version bump to 0.24
this version has some bug fixes and GHDL's man-page.
Comment 27 hiyuh 2006-06-29 04:25:01 UTC
the ebuild on the above required ghdl-0.23.patch.
it's Joe's patch for ghdl-0.21 in this bug report.
Comment 28 Denis Dupeyron gentoo-dev 2006-07-08 02:14:54 UTC
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.
Comment 29 hiyuh 2006-08-14 08:57:01 UTC
Comment on attachment 90413 [details]
a ebuild for ghdl-0.24

fix silly typo (0.2.4 -> 0.24)
Comment 30 hiyuh 2006-08-14 09:27:53 UTC
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...
Comment 31 Timothy Stotts 2006-08-31 10:26:26 UTC
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 .
Comment 32 hiyuh 2006-09-26 10:13:21 UTC
Created attachment 98144 [details, diff]
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. :)
Comment 33 George Shapovalov (RETIRED) gentoo-dev 2007-01-29 09:27:03 UTC
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
Comment 34 Denis Dupeyron gentoo-dev 2007-01-29 12:08:58 UTC
(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.
Comment 35 Matti Bickel (RETIRED) gentoo-dev 2007-06-02 20:35:05 UTC
There is ghdl-0.26 released upstream. If i find the time next week, i will take a look at it.
Comment 36 Denis Dupeyron gentoo-dev 2007-06-05 21:56:02 UTC
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.
Comment 37 Denis Dupeyron gentoo-dev 2007-06-11 21:19:35 UTC
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.
Comment 38 hiyuh 2007-06-13 07:45:43 UTC
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
Comment 39 Timothy Stotts 2007-06-13 12:04:19 UTC
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"
Comment 40 Timothy Stotts 2007-06-13 12:07:06 UTC
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'.
Comment 41 Denis Dupeyron gentoo-dev 2007-06-13 20:40:39 UTC
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.
Comment 42 hiyuh 2007-06-21 20:17:47 UTC
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
Comment 43 Denis Dupeyron gentoo-dev 2007-06-29 21:23:19 UTC
(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.