[Pkg-electronics-devel] Packaging GHDL yosys plugin

[Andreas Bombe]

Sorry, haven't gotten around to looking at it more before.

On Tue, Jan 11, 2022 at 08:17:14AM +0100, dxld at darkboxed.org wrote:
> Hi Andreas,
> 
> so I just discovered another problem with just having libghdl as part of
> the main ghdl backend package.
> 
> The yosys plugin is built with overriden RPATH so that the dynamic linker
> can find libgdhl, which is installed in /usr/lib/ghdl/<backend> currently
> so it wouldn't be found otherwise. This causes lintian errors because of
> https://wiki.debian.org/RpathIssue.
> 
> So it seems we really do have to go the seperate library package route or
> static linking to package this properly.

I don't like static linking and that is also discouraged in Debian.
Interestingly the VPI library is statically linked, but when creating a
module it gets dynamically linked in (with RPATH). Anyway, that module
has to be loaded by running ghdl with the right options, it doesn't
really get used standalone.

That's why I felt it was okay to install an unversioned library into a
package internal directory. It so happens that gcc and llvm built
simulations can be run directly, but the official way is to run it
through the ghdl executable. So there is really no expectation that
those binaries can be installed permanently or would be compatible
between ghdl versions.

Back to libghdl however: I had a quick look into the ghdl docker image,
which would be sort of an official binary build of upstream ghdl. There
the installed libghdl looks to have a somewhat reasonable SONAME and if
upstream keeps versioning that reasonably with future changes we could
go with that.

And as long as that library is fully independent and does not itself
call the ghdl binaries. I'm not sure what interactions that could have
and having to soname version the regular ghdl packages is not feasible.

Anyway, in the near future I wanted to enable automated testing in the
ghdl package. Updating to a git snapshot and adding the libghdl (and the
Python packages, also depending on libghdl) could come afterwards.

> --Daniel
> 
> On Thu, Jan 06, 2022 at 03:58:22AM +0100, dxld at darkboxed.org wrote:
> > Hi Andreas,
> > 
> > thanks for getting back to me.
> > 
> > On Thu, Jan 06, 2022 at 03:35:18AM +0100, Andreas Bombe wrote:
> > > > Installing it alongside libghdlvpi.so is questionable, I think. My
> > > understanding is that the VPI lib is only used by simulation binaries
> > > built by ghdl, so there is no real need for versioning (the installed
> > > library would match the ghdl, and the simulation binary built by ghdl
> > > would therefore match the library). The dependency is transient, and if
> > > a new ghdl is installed the simulation binaries would need to be
> > > regenerated.
> > 
> > I feel its a bit suboptimal that libghdlvpi isn't installed as it's own
> > (versioned) library package if it does get used by simulation executables
> > built by ghdl as you say. Seems to me this should be handled no different
> > from something like libgcc, no?
> > 
> > That being said ofc. the impact here is a lot smaller and until someone
> > actually wants to install simulation binaries in a debian package it's
> > probably not worth the hassle indeed.
> > 
> > > If ghdl-yosys-plugin becomes a package, I assume it would have to depend
> > > on a specific ghdl version if it is installed like this. This would
> > > require making a new version of the plugin every time ghdl is updated.
> > > Otherwise the library needs to be properly versioned, or the plugin
> > > needs to be effectively included in the ghdl package rather than
> > > packaged separately.
> > 
> > I take your point about libghdl. If we package a plugin that depends on it
> > having it lumped in with ghdl is going to spell trouble. I was intially
> > going to pull it out into it's own package but decided against it because I
> > wasn't sure how the headers and such would have to be distributed across
> > the -dev and -common packages.
> > 
> > Your idea about including the plugin in the ghdl source package sounds
> > interesting. One thing I've seen in other packages is using "multiple
> > source tarballs"[1] where we could bundle ghdl and the yosys plugin into
> > one source package but with separate tarballs. It is probably a bit
> > unconventional for the upstreams to be different in this case, so I'm not
> > sure it's a good idea.
> > 
> > [1]: https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/
> > 
> > Another way to solve the problem would be to not install the libghd*.so but
> > only the static library, then ghdl uploads wouldn't require an immediate
> > rebuild of the plugin only some time before release to ensure it doesn't
> > FTBFS with the new version.
> > 
> > Tough here I'm not sure how such rebuilds are handled in Debian, I know for
> > a fact that Haskell and Rust packaging do things like this, but I suspect
> > they have bespoke mechanisms to ensure packages are rebuilt/updated as
> > necessary.
> > 
> > > For the aforementioned reasons, please do not attempt any such changes
> > > to the package yet.
> > 
> > Sure, no problem. I'll have a look at splitting libghdl into a separate
> > package and see how that goes then. Let me know if you find or decide on
> > another solution though.
> > 
> > Thanks,
> > --Daniel
> > 
> > PS: Do you think we should bounce this and the earlier mails to
> > debian-electronics (or some other list) so other people can chime in?

Yes, I'm copying this to the list now.