documentation for application developers?

  • Open
  • quality assurance status badge
Details
4 participants
  • Bruno Haible
  • Danny Milosavljevic
  • Ludovic Courtès
  • Tobias Geerinckx-Rice
Owner
unassigned
Submitted by
Bruno Haible
Severity
minor
B
B
Bruno Haible wrote on 3 May 2020 01:36
(address . bug-guix@gnu.org)
1614037.PG1mooiXeX@omega
Hi,

I'm searching for documentation for application developers, regarding
tips for porting from ordinary Linux distros to GNU guix.

I would expect to find these issues discussed, at least:
- hard-coded program names like /bin/pwd
- where is /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ?
- libtool, ldconfig issues

Haven't seen it in
nor

Bruno
L
L
Ludovic Courtès wrote on 3 May 2020 22:59
(name . Bruno Haible)(address . bruno@clisp.org)(address . 41037@debbugs.gnu.org)
87pnbkvio0.fsf@gnu.org
HI Bruno,

Bruno Haible <bruno@clisp.org> skribis:

Toggle quote (3 lines)
> I'm searching for documentation for application developers, regarding
> tips for porting from ordinary Linux distros to GNU guix.

There’s no such documentation. However, for applications that follow
“good practices”, there really isn’t any porting to do.

Toggle quote (3 lines)
> I would expect to find these issues discussed, at least:
> - hard-coded program names like /bin/pwd

These should be avoided; it’s not Guix-specific, but the problem is
obviously more acute here. What Guix packages do is patch them.

Toggle quote (2 lines)
> - where is /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ?

It’s in the glibc package:

ls $(guix build glibc | grep '[0-9]$')/lib

What’s your use case?

Toggle quote (2 lines)
> - libtool, ldconfig issues

‘ldconfig’ is not used. Nothing special for Libtool.
Do you have something in mind?

Thanks,
Ludo’.
B
B
Bruno Haible wrote on 3 May 2020 23:13
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41037@debbugs.gnu.org)
10121112.yT0VcRYgiK@omega
Hi Ludo,

Toggle quote (6 lines)
> > I would expect to find these issues discussed, at least:
> > - hard-coded program names like /bin/pwd
>
> These should be avoided; it’s not Guix-specific, but the problem is
> obviously more acute here.

/bin/pwd exists on all other Unix systems; so de facto it _is_ Guix
specific.

Toggle quote (8 lines)
> > - where is /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ?
>
> It’s in the glibc package:
>
> ls $(guix build glibc | grep '[0-9]$')/lib
>
> What’s your use case?

So, the consequence is that a Guix user cannot send an executable
to another Guix user and expect it to be runnable on the other machine.
This too is Guix specific; maybe it is already documented?

Toggle quote (5 lines)
> > - libtool, ldconfig issues
>
> ‘ldconfig’ is not used. Nothing special for Libtool.
> Do you have something in mind?

I wanted to have background information regarding ldconfig and shared
library caches, in order to investigate bug#41038

Bruno
D
D
Danny Milosavljevic wrote on 3 May 2020 23:48
(name . Bruno Haible)(address . bruno@clisp.org)
20200503234833.3f078d0e@scratchpost.org
Hi Bruno,

On Sun, 03 May 2020 23:13:46 +0200
Bruno Haible <bruno@clisp.org> wrote:

Toggle quote (3 lines)
> So, the consequence is that a Guix user cannot send an executable
> to another Guix user and expect it to be runnable on the other machine.

Do you mean only one file, the executable? That doesn't work well with any
other distribution either.

What guix can do is pack everything a package needs into a tarball
(including dependencies too) and then put that on another machine.
The command is "guix pack" (it can also create Docker containers
and Singularity images--but regular tarballs work just fine).
That does work reliably, and automatically does deduplication.

Toggle quote (4 lines)
> I wanted to have background information regarding ldconfig and shared
> library caches, in order to investigate bug#41038
> <https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00036.html>.

ldconfig is not used in Guix. Guix uses rpath in order to embed the
entire path to each of the shared libraries that are used into the
executable.
ldconfig's name resolution is disabled.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl6vPDEACgkQ5xo1VCww
uqUingf9H73NdiAHH67aM1bnjqlrq00hrA0KrC0PZPtxafO/FMDgWiTqDT2JXS8S
Ywg7fL6fwOeeKnPAQ5Bpg4g7QgJJfnbaHTTxqCPL5pACr062qOGNLpALuG1ivv/+
asKdXHrphY1cZUj8zcw+Q0WR0dY2E5nkHb2rhlTm7kpwE+KoQ5tyPvnr6dfO8JrS
eFdPsh96Dc/NEUKDPoDHEaPW/IBrHUMYDgEO87XLOOHiJ2S8KJslGzSVk3oZ2372
QwSRslDj8kxV3Uzl60ko5hKBZN22RZPGGgDNZrgdnHd/6N00KPkahtDQgjG2ZIVZ
xUX/LNoRtOQHly3CSPKWvOt+7Nr2Rg==
=je1C
-----END PGP SIGNATURE-----


T
T
Tobias Geerinckx-Rice wrote on 4 May 2020 00:18
(address . 41037@debbugs.gnu.org)
87imhcr7jg.fsf@nckx
Hi Bruno!

Bruno Haible ???
Toggle quote (13 lines)
> Hi Ludo,
>
>> > I would expect to find these issues discussed, at least:
>> > - hard-coded program names like /bin/pwd
>>
>> These should be avoided; it’s not Guix-specific, but the
>> problem is
>> obviously more acute here.
>
> /bin/pwd exists on all other Unix systems; so de facto it _is_
> Guix
> specific.

Perhaps. Well behaved portable programmes use $PATH anyway, so
it's a non-issue.

A handful hard-code directories at their peril and suffer the
consequences — usually, by being patched to respect $PATH. :-)

This is deliberately not supported. Users *could* ask Guix to
create a /bin/pwd for them. Nobody does.

Toggle quote (5 lines)
> So, the consequence is that a Guix user cannot send an
> executable
> to another Guix user and expect it to be runnable on the other
> machine.

s|Guix|GNU/Linux|g

Toggle quote (2 lines)
> This too is Guix specific; maybe it is already documented?

It's not Guix-specific at all. It's universal to all unix systems
(and beyond): when you send someone a binary that's missing
external dependencies, it will not run. If you give them the
dependencies (for example, using ‘guix pack’ which includes the
correct linker, not someone else's random copy with the same
name), it runs. Guix is no different.

Toggle quote (2 lines)
> ldconfig and shared library caches

Guix uses neither, since there's nothing to cache: once linked
(using rpath and absolute /gnu/store file names), libraries do not
move around in space and time. It's not the cause of or the
solution to your problem. I hope Ludo's suggestion was!

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQT12iAyS4c9C3o4dnINsP+IT1VteQUCXq9DHQAKCRANsP+IT1Vt
eXDMAQDtSog1+cTgfqGadxR8uEBFCsofRv3EZZTqRFpn1qwoMQEAzO27/L2k69Gi
PfOqPgK1XprO3ZQA+W8k53S2Dm4ItwQ=
=wnCG
-----END PGP SIGNATURE-----

B
B
Bruno Haible wrote on 4 May 2020 00:57
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
2285415.SFTs44rKTU@omega
Hi Danny,

Toggle quote (6 lines)
> > So, the consequence is that a Guix user cannot send an executable
> > to another Guix user and expect it to be runnable on the other machine.
>
> Do you mean only one file, the executable? That doesn't work well with any
> other distribution either.

Huh? I thought the purpose of the LSB specification is precisely that you
can take an executable from any modern Linux distro and run it on any other
modern Linux distro, with high success probability (not 100%, but close).

But when the different systems have the ld.so at different absolute locations,
it doesn't work.

Toggle quote (6 lines)
> What guix can do is pack everything a package needs into a tarball
> (including dependencies too) and then put that on another machine.
> The command is "guix pack" (it can also create Docker containers
> and Singularity images--but regular tarballs work just fine).
> That does work reliably, and automatically does deduplication.

This is well documented in the manual. It's the other part, about
the "naked" executables, that I would have expected to find in the
documentation.

Toggle quote (9 lines)
> > I wanted to have background information regarding ldconfig and shared
> > library caches, in order to investigate bug#41038
> > <https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00036.html>.
>
> ldconfig is not used in Guix. Guix uses rpath in order to embed the
> entire path to each of the shared libraries that are used into the
> executable.
> ldconfig's name resolution is disabled.

This is valuable info! Can you just add this paragraph to the doc, please?

Bruno
L
L
Ludovic Courtès wrote on 4 May 2020 10:18
(name . Bruno Haible)(address . bruno@clisp.org)(address . 41037@debbugs.gnu.org)
87v9lct8o9.fsf@gnu.org
Hi,

Bruno Haible <bruno@clisp.org> skribis:

Toggle quote (9 lines)
>> It’s in the glibc package:
>>
>> ls $(guix build glibc | grep '[0-9]$')/lib
>>
>> What’s your use case?
>
> So, the consequence is that a Guix user cannot send an executable
> to another Guix user and expect it to be runnable on the other machine.

True (but that’s generally the case on GNU/Linux and the reason why
things like Flatpak were built.)

To send an executable to another Guix machine, one would use ‘guix
copy’:


But more generally, people would share “channels” containing complete
build-from-source instructions, along with “substitutes” (pre-built
binaries):


HTH,
Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 41037@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 41037
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch