Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#66387 - [freehdl] undefined reference to `L4ieee_Q14std_logic_1164_Y0y0_i57

Attached to Project: Community Packages
Opened by Vladimir (v_2e) - Friday, 24 April 2020, 22:02 GMT
Last edited by freswa (frederik) - Friday, 24 April 2020, 22:41 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

Description:

In fact, with this bugreport I would like to report several issues at once, because their separate reporting seems to violate the Arch bug reporting rules. I also suggest my patches to fix these bugs -- in case this can be done within the established Arch packaging process.

First of all, in its current state (since about early 2018, I guess) FreeHDL seems to be unusable at all. There are several bugreports and forum topics on it segfaulting each time even for the simplest VHDL files.

As FreeHDL is often used in conjunction with the QUCS simulator, its functionality is also often tested and discussed together with QUCS. As far as I can tell from my own experience and from the mentioned reports by other people, QUCS has been unable to perform even the simplest digital simulations using FreeHDL since at least 2018.

All these bugs definitely belong to upstream, but unfortunately, there seem to be no active upstream. The official FreeHDL website does not even ship the files for the version 0.0.8 any more. That is the main reason I decided to share all my patches here and ask for the Maintainer's opinion on what to do next.

So let me single out several problems:

1. Compilation problems on relatively modern systems with relatively fresh compiler versions (deprecated functions and so on). These problems are (maybe partially, and maybe completely -- I am not sure) are solved by the 'build-fix.patch' currently present in Arch repository.

I suggest another patch called 'cpp-modern.patch'. Again, I am not 100% sure, but it seems to fix the same issues and adds some more fixes to the source code.

And also I had to add the '-D_GLIBCXX_USE_CXX11_ABI=1' compile option in order to build and use FreeHDL successfully.



2. Even when successfully built and installed, FreeHDL segfaults even for the simplest VHDL file conversion to CC.

This bug is kind of "fixed" with the 'declerative_region.patch'.


3. The issue mentioned in the title. After fixing the above, the linking of the FreeHDL-generated CC files fails with the following error message:


libtool: link: g++ digi._main_.o digi.o -o digi -L/lib/freehdl /usr/lib/libfreehdl-kernel.so /usr/lib/libfreehdl-std.so /usr/lib/freehdl/libieee.so -Wl,-rpath -Wl,/usr/lib/freehdl -Wl,-rpath -Wl,/usr/lib/freehdl
/usr/bin/ld: digi.o: in function `L4work_E9testbench_A14arch_testbench_P5_10pn::execute()':
digi.cc:218: undefined reference to `L4ieee_Q14std_logic_1164_Y0y0_i57(unsigned char, unsigned char)'
collect2: error: ld returned 1 exit status


I tracked down this issue about two years ago and reported it on Gentoo Bugzilla. This happens because the upstream sources tree contains the unnecessary CC files in 'ieee' subdirectory. These files must be generated during the build process, and therefore they must be removed beforehand.


4. When all above is fixed, and the FreeHDL-generated CC program compiles fine, it still crashes because of the NULL pointer. I fixed this bug with the 'acl-NULL-check.patch'. It contains some stupid code insets made by me, but also it checks against the NULL pointers.


5. There are also a couple of patches I am not sure about. One of them I took from the Gentoo QA team -- it is called 'gentoo-qa.patch', and another one is called 'gvhdl_tag_command.patch' -- I imported it from Ubuntu sources. I have no idea what it actually fixes.


As a result, using all these patches and build scripts, I succeeded in packaging a working FreeHDL for Arch and Ubuntu (also tested on Manjaro and LinuxMint). It would be a pity if other people could not use my findings in their work if they also need the digital simulation in QUCS.

I read the 'Bug reporting guidelines', and it says 'If Arch is not responsible for a bug, the problem will not be solved by reporting the bug to Arch developers.' in bold font, so among all the issues I described, I chose the one directly related to the packaging process as the bug's title.

And my question is: is it acceptable to add all these patches to the official Arch repository and repackage FreeHDL incorporating them, taking into account the seemingly dead upstream? If it is not acceptable, should I submit my files to AUR and create a 'freehdl' package there?


I hope my patches and observations will be useful, and I would be very grateful for your advice on the reasonable further actions.

Thank you!


Additional info:
* package version(s) 0.0.8

This task depends upon

Loading...