A question about pure static linking with libdl

A question about pure static linking with libdl

[John Hu]

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

Dear musl developers,

Recently I have an experiment about whether full static-linked ld.gold with
plugin function enabled can use its --plugin option to dynamically load
plugins such as LLVMgold.so. I use "./configure --enable --enable-plugins
--disable-werror LDFLAGS="-static" "  to generate a full statically linked
ld.gold which does not have any dynamic library dependency, then I exec
"./ld.gold --plugin LLVMgold.so" but an error occurs that "could not load
plugin library: Dynamic loading not supported". I doubt this is a bug
because it is claimed that musl supports full static linking but I am not
sure about that. BTW, my experiment environment is Alpine 3.5.

Now I send this email again because I want this email to be replied
according to "If you are not subscribed and want to receive a reply, please
mention in your email that you want to be Cc'd." in the website.

[-- Attachment #2: Type: text/html, Size: 1237 bytes --]

Re: A question about pure static linking with libdl

[Szabolcs Nagy]

* John Hu <heat0415@gmail.com> [2017-05-16 15:40:28 +0800]:
> Recently I have an experiment about whether full static-linked ld.gold with
> plugin function enabled can use its --plugin option to dynamically load
> plugins such as LLVMgold.so. I use "./configure --enable --enable-plugins
> --disable-werror LDFLAGS="-static" "  to generate a full statically linked
> ld.gold which does not have any dynamic library dependency, then I exec
> "./ld.gold --plugin LLVMgold.so" but an error occurs that "could not load
> plugin library: Dynamic loading not supported". I doubt this is a bug
> because it is claimed that musl supports full static linking but I am not
> sure about that. BTW, my experiment environment is Alpine 3.5.

dlopen is not supported in static linked binaries yet, that is non-trivial
to support and in your use case it does not make sense: the loaded lib is
linked against the host libc (and many other libs) and is in a package that
is updated independently of the libc, there is no guarantee that the static
linked libc is compatible with the host libc (and if there is then you
don't really need static linking anyway, you could get the same effect
by using your custom libc to launch ld.gold as ./mylibc.so ld-gold ).

> 
> Now I send this email again because I want this email to be replied
> according to "If you are not subscribed and want to receive a reply, please
> mention in your email that you want to be Cc'd." in the website.

Re: A question about pure static linking with libdl

[John Hu]

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

Dear Mr.Nagy,

First thanks for your sincere reply but I still have some questions. The
reason why I do this test is that I want to build my project on my machine
and distribute it to any other Linux (I can't ask other people to compile
my project on their machine, that is totally unacceptable). I think full
static linking can do this. Since full static linking does not support
dlopen I made another test: generate ld.gold that ONLY dynamic links with
musl-libc(libc.so) and so does LLVMgold.so. Then I copy them to Ubuntu
16.04 and exec ldd command on both and I found that "libc.musl-x86_64.so.1
=> not found"  in the output. Finally I exec "./ld.gold --plugin
LLVMgold.so" and an error occurred that "could not load plugin library:
libc.musl-x86_64.so.1: cannot open shared object file: No such file or
directory". I test the basic function of these two files that works well
because they can find glibc ld.so on Ubuntu16.04 as ldd shows.
Now I have no idea how to workaround this problem, my question is that
whether there is a way that generating some binary executable files in one
system and they are portable and compatible on any other Linux
distributions (means these binary files can run normally without any
problem).

2017-05-16 18:30 GMT+08:00 Szabolcs Nagy <nsz@port70.net>:

> * John Hu <heat0415@gmail.com> [2017-05-16 15:40:28 +0800]:
> > Recently I have an experiment about whether full static-linked ld.gold
> with
> > plugin function enabled can use its --plugin option to dynamically load
> > plugins such as LLVMgold.so. I use "./configure --enable --enable-plugins
> > --disable-werror LDFLAGS="-static" "  to generate a full statically
> linked
> > ld.gold which does not have any dynamic library dependency, then I exec
> > "./ld.gold --plugin LLVMgold.so" but an error occurs that "could not load
> > plugin library: Dynamic loading not supported". I doubt this is a bug
> > because it is claimed that musl supports full static linking but I am not
> > sure about that. BTW, my experiment environment is Alpine 3.5.
>
> dlopen is not supported in static linked binaries yet, that is non-trivial
> to support and in your use case it does not make sense: the loaded lib is
> linked against the host libc (and many other libs) and is in a package that
> is updated independently of the libc, there is no guarantee that the static
> linked libc is compatible with the host libc (and if there is then you
> don't really need static linking anyway, you could get the same effect
> by using your custom libc to launch ld.gold as ./mylibc.so ld-gold ).
>
> >
> > Now I send this email again because I want this email to be replied
> > according to "If you are not subscribed and want to receive a reply,
> please
> > mention in your email that you want to be Cc'd." in the website.
>

[-- Attachment #2: Type: text/html, Size: 3444 bytes --]

Re: A question about pure static linking with libdl

[Jon Chesterfield]

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

I think using dlopen in static binaries is an interesting (though niche)
use case. I'm subscribed to this list with a vague intention of
implementing it but haven't found the time.

The application of interest to me is a plugin architecture where the main
executable is static, mostly so it's easier to distribute, and the plugged
in components are independent of any libc. Essentially trying to use elf as
part of a jit loading mechanism.

No eta on this work though. Could be years :(

Cheers

On 16 May 2017 17:30, "Szabolcs Nagy" <nsz@port70.net> wrote:

* John Hu <heat0415@gmail.com> [2017-05-16 15:40:28 +0800]:
> Recently I have an experiment about whether full static-linked ld.gold
with
> plugin function enabled can use its --plugin option to dynamically load
> plugins such as LLVMgold.so. I use "./configure --enable --enable-plugins
> --disable-werror LDFLAGS="-static" "  to generate a full statically linked
> ld.gold which does not have any dynamic library dependency, then I exec
> "./ld.gold --plugin LLVMgold.so" but an error occurs that "could not load
> plugin library: Dynamic loading not supported". I doubt this is a bug
> because it is claimed that musl supports full static linking but I am not
> sure about that. BTW, my experiment environment is Alpine 3.5.

dlopen is not supported in static linked binaries yet, that is non-trivial
to support and in your use case it does not make sense: the loaded lib is
linked against the host libc (and many other libs) and is in a package that
is updated independently of the libc, there is no guarantee that the static
linked libc is compatible with the host libc (and if there is then you
don't really need static linking anyway, you could get the same effect
by using your custom libc to launch ld.gold as ./mylibc.so ld-gold ).

>
> Now I send this email again because I want this email to be replied
> according to "If you are not subscribed and want to receive a reply,
please
> mention in your email that you want to be Cc'd." in the website.

[-- Attachment #2: Type: text/html, Size: 2790 bytes --]

Re: A question about pure static linking with libdl

[Szabolcs Nagy]

* Jon Chesterfield <jonathanchesterfield@gmail.com> [2017-06-10 12:19:43 +0100]:
> I think using dlopen in static binaries is an interesting (though niche)
> use case. I'm subscribed to this list with a vague intention of
> implementing it but haven't found the time.
> 
> The application of interest to me is a plugin architecture where the main
> executable is static, mostly so it's easier to distribute, and the plugged
> in components are independent of any libc. Essentially trying to use elf as
> part of a jit loading mechanism.
> 
> No eta on this work though. Could be years :(

to do that the application must contain everything from libc
that may be needed by the loaded plugins (since you dont want
to load another libc when one is already static linked)

the easiest way is to just put all of libc into your application
(or put your application into libc: e.g. put your application code
into the musl repo and change the dynamic linker startup code to
jump to your app, then the produced libc.so will do dynamic linking
and then runs your app, dlopen works and it's a self-contained binary)

otoh this wont work well for loading jited code: if you generate
lot of executable code, then you will need unload support too to
get rid of the unused contents, in musl dlclose is a noop so the
address space will keep filling up.

Re: A question about pure static linking with libdl

[Rich Felker]

On Sat, Jun 10, 2017 at 06:37:33PM +0200, Szabolcs Nagy wrote:
> * Jon Chesterfield <jonathanchesterfield@gmail.com> [2017-06-10 12:19:43 +0100]:
> > I think using dlopen in static binaries is an interesting (though niche)
> > use case. I'm subscribed to this list with a vague intention of
> > implementing it but haven't found the time.
> > 
> > The application of interest to me is a plugin architecture where the main
> > executable is static, mostly so it's easier to distribute, and the plugged
> > in components are independent of any libc. Essentially trying to use elf as
> > part of a jit loading mechanism.
> > 
> > No eta on this work though. Could be years :(
> 
> to do that the application must contain everything from libc
> that may be needed by the loaded plugins (since you dont want
> to load another libc when one is already static linked)
> 
> the easiest way is to just put all of libc into your application
> (or put your application into libc: e.g. put your application code
> into the musl repo and change the dynamic linker startup code to
> jump to your app, then the produced libc.so will do dynamic linking
> and then runs your app, dlopen works and it's a self-contained binary)
> 
> otoh this wont work well for loading jited code: if you generate
> lot of executable code, then you will need unload support too to
> get rid of the unused contents, in musl dlclose is a noop so the
> address space will keep filling up.

For the jit'd code usage case I think it makes more sense to just
write your own minimal ELF loader that's not tied into the global
symbol table and dynamic linking semantics. Then you can unload it
freely and don't have to worry about interaction with other things.
Perhaps someday I should write a poc for doing this. It should only
take a few hundred loc and should be essentially arch-independent just
like musl's relocation code (just needing arch-reloc-to-generic
mappings like musl uses).

Rich

A question about pure static linking with libdl

[John Hu]

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

Dear musl developers,

Recently I have an experiment about whether full static-linked ld.gold with
plugin function enabled can use its --plugin option to dynamically load
plugins such as LLVMgold.so. I use "./configure --enable --enable-plugins
--disable-werror LDFLAGS="-static" "  to generate a full statically linked
ld.gold which does not have any dynamic library dependency, then I exec
"./ld.gold --plugin LLVMgold.so" but an error occurs that "could not load
plugin library: Dynamic loading not supported". I doubt this is a bug
because it is claimed that musl supports full static linking but I am not
sure about that. BTW, my experiment environment is Alpine 3.5.

[-- Attachment #2: Type: text/html, Size: 762 bytes --]