bug#41037: documentation for application developers?

bug#41037: documentation for application developers?

[Bruno Haible]

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
  https://guix.gnu.org/
nor
  https://guix.gnu.org/manual/en/guix.html

Bruno

bug#41037: documentation for application developers?

[Ludovic Courtès]

HI Bruno,

Bruno Haible <bruno@clisp.org> skribis:

> 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.

> 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.

>   - 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?

>   - libtool, ldconfig issues

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

Thanks,
Ludo’.

bug#41037: documentation for application developers?

[Bruno Haible]

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.

> >   - 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?

> >   - 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
<https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00036.html>.

Bruno

bug#41037: documentation for application developers?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Hi Bruno,

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

> 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.

> 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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#41037: documentation for application developers?

[Bruno Haible]

Hi Danny,

> > 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.

> 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.

> > 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

bug#41037: documentation for application developers?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

Hi Bruno!

Bruno Haible 写道：
> 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.

> 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

> 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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#41037: documentation for application developers?

[Ludovic Courtès]

Hi,

Bruno Haible <bruno@clisp.org> skribis:

>> 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’:

  https://guix.gnu.org/manual/en/html_node/Invoking-guix-copy.html

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

  https://guix.gnu.org/manual/en/html_node/Channels.html
  https://guix.gnu.org/manual/en/html_node/Substitutes.html

HTH,
Ludo’.