Discussion:
Bug#807924: ghc: empty haddock interface version on hurd-i386
Add Reply
Samuel Thibault
2015-12-14 14:40:03 UTC
Reply
Permalink
Source: ghc
Version: 7.10.3-4
Severity: important

On the hurd-i386 port, the ghc package has

Provides: ghc-dynamic, ghc-ghci, ghc-haddock, haddock,
haddock-interface-, etc.

while on other ports, it provides haddock-interface-27. I don't know
how this is supposed to be computed, but it seems that that fails on
hurd-i386.

Samuel

-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
Samuel
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
Joachim Breitner
2015-12-14 15:00:02 UTC
Reply
Permalink
Hi,
Post by Samuel Thibault
Source: ghc
Version: 7.10.3-4
Severity: important
On the hurd-i386 port, the ghc package has
Provides: ghc-dynamic, ghc-ghci, ghc-haddock, haddock,
haddock-interface-, etc.
while on other ports, it provides haddock-interface-27.  I don't know
how this is supposed to be computed, but it seems that that fails on
hurd-i386.
This is computed by this line in debian/rules:

        echo "haddock:Depends=haddock-interface-$$(debian/tmp/usr/lib/ghc/bin/haddock --interface-version)" >> debian/ghc-doc.substvars
        echo "haddock:Provides=haddock-interface-$$(debian/tmp/usr/lib/ghc/bin/haddock --interface-version)" >> debian/ghc.substvars

Maybe the haddock executable is broken on hurd? What happens if you install ghc and run haddock --interface-version?

Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
***@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
JID: ***@joachim-breitner.de | http://people.debian.org/~nomeata
Samuel Thibault
2015-12-14 15:30:03 UTC
Reply
Permalink
Post by Joachim Breitner
Maybe the haddock executable is broken on hurd? What happens if you install ghc and run haddock --interface-version?
I get 27

Samuel
Joachim Breitner
2015-12-14 15:50:03 UTC
Reply
Permalink
Hi,
Post by Samuel Thibault
Post by Joachim Breitner
Maybe the haddock executable is broken on hurd? What happens if you
install ghc and run haddock --interface-version?
I get 27
ah, looking at the build log I find suspicious messages:

debian/tmp/usr/lib/ghc/bin/haddock: error while loading shared libraries: libHSxhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh-ghc7.10.3.so: cannot open shared object file: No such file or directory

so it seems like it does not find the shared library, which is also
built in the process. It does so on other architectures. I don’t know
off-hand by what mechanism the build system ensures that these are
found, but I’d bet on rpath. Does hurd handle rpaths differently?

Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
***@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
JID: ***@joachim-breitner.de | http://people.debian.org/~nomeata
Samuel Thibault
2015-12-15 00:00:02 UTC
Reply
Permalink
I don’t know off-hand by what mechanism the build system ensures
that these are found, but I’d bet on rpath. Does hurd handle rpaths
differently?
It does support rpath. ghc apparently uses $ORIGIN in rpath. IIRC we
added some support for that, perhaps it's not enough.

Samuel
Samuel Thibault
2015-12-15 00:20:01 UTC
Reply
Permalink
Post by Samuel Thibault
I don’t know off-hand by what mechanism the build system ensures
that these are found, but I’d bet on rpath. Does hurd handle rpaths
differently?
It does support rpath. ghc apparently uses $ORIGIN in rpath. IIRC we
added some support for that, perhaps it's not enough.
No, some patches exist, but they have not been commited, so $ORIGIN is
not supported yet.

Samuel
Joachim Breitner
2015-12-15 08:20:01 UTC
Reply
Permalink
Hi,
Post by Samuel Thibault
I don’t know off-hand by what mechanism the build system ensures
that these are found, but I’d bet on rpath. Does hurd handle rpaths
differently?
It does support rpath.  ghc apparently uses $ORIGIN in rpath.  IIRC we
added some support for that, perhaps it's not enough.
No, some patches exist, but they have not been commited, so $ORIGIN is
not supported yet.
I see. 

The rpath is used by the upstream build system to make sure the
executable works even in-tree or (in this case) in-$DESTDIR.

It might be possible to work around the issue by manually setting some
LD_LIBRARY_PATH entries in debian/rules. 

I don’t think I’ll get to work on that before christmas, but patches
welcome.

Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
***@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
JID: ***@joachim-breitner.de | http://people.debian.org/~nomeata
Samuel Thibault
2019-08-12 00:40:02 UTC
Reply
Permalink
Control: reassign -1 hurd
Control: close -1 1:0.9.git20180108-1
Post by Samuel Thibault
Post by Samuel Thibault
I don’t know off-hand by what mechanism the build system ensures
that these are found, but I’d bet on rpath. Does hurd handle rpaths
differently?
It does support rpath. ghc apparently uses $ORIGIN in rpath. IIRC we
added some support for that, perhaps it's not enough.
No, some patches exist, but they have not been commited, so $ORIGIN is
not supported yet.
This was fixed in the Hurd package.

Samuel

Loading...