unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Linking to libraries in the ELF?
@ 2021-01-29 16:20 Maxime Devos
  2021-03-09 21:04 ` Andy Wingo
  0 siblings, 1 reply; 2+ messages in thread
From: Maxime Devos @ 2021-01-29 16:20 UTC (permalink / raw)
  To: guile-devel


[-- Attachment #1.1: Type: text/plain, Size: 375 bytes --]

Hi guilers,

I've got this crazy idea a few days ago, about the FFI interface.
When a program written in C is compiled with some shared libraries,
these libraries are referred to in special [insert ELF terminology
here] of the binary.  I wonder if it would be reasonable and feasible
to do something similar for compiles guile modules?

C example:
$ readelf -d `which guile`

[-- Attachment #1.2: Type: text/plain, Size: 429 bytes --]

  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libguile-3.0.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libgc.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libffi.so.7]
 [snip]
 0x000000000000001d (RUNPATH)            Library runpath: [[snip]]
 [snip]

[-- Attachment #1.3: Type: text/plain, Size: 115 bytes --]


Hypothetical Scheme example:
$ readelf -d $HOME/.guix-profile/lib/guile/3.0/site-ccache/chickadee/audio/vorbis.go

[-- Attachment #1.4: Type: text/plain, Size: 539 bytes --]

  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libvorbisfile.so.3]
 0x000000000000001d (RUNPATH)            Library runpath: [[snip]]
 0x0000000037146003 (<unknown>: 37146003) 0x3000002
 0x0000000037146002 (<unknown>: 37146002) 0xe8
 0x0000000037146000 (<unknown>: 37146000) 0x20000
 0x0000000037146001 (<unknown>: 37146001) 0xaaa0
 0x000000000000000c (INIT)               0x6bd0
 0x0000000037146004 (<unknown>: 37146004) 0x15530
 0x0000000000000000 (NULL)               0x0

[-- Attachment #1.5: Type: text/plain, Size: 195 bytes --]


This would require fleshing out some details though,
such as when to use RUNPATH and when not, cross-platform support,
where to find the libraries, some things I probably forgot.

WDYT?

Maxime

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Linking to libraries in the ELF?
  2021-01-29 16:20 Linking to libraries in the ELF? Maxime Devos
@ 2021-03-09 21:04 ` Andy Wingo
  0 siblings, 0 replies; 2+ messages in thread
From: Andy Wingo @ 2021-03-09 21:04 UTC (permalink / raw)
  To: Maxime Devos; +Cc: guile-devel

On Fri 29 Jan 2021 17:20, Maxime Devos <maximedevos@telenet.be> writes:

> I've got this crazy idea a few days ago, about the FFI interface.
> When a program written in C is compiled with some shared libraries,
> these libraries are referred to in special [insert ELF terminology
> here] of the binary.  I wonder if it would be reasonable and feasible
> to do something similar for compiles guile modules?

These sections of executables or shared libraries are actually
*interpreted* by the system dynamic library loader, ld.so.  Guile has
its own loader, independent of ld.so, and so can implement this -- or do
more flexible things.  In any case we probably shouldn't tie ourselves
to the particular implementation of a particular loader.

Of course, dynamic-link was... not a great interface.  But with the
recent changes in git I think it can be fine (see "Foreign Libraries" in
the manual).  For the FFI the bigger problem IMO is generating faster
foreign procedure bindings -- i.e. farther on the
compilation-vs-interpretation scale.

Cheers,

Andy



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-03-09 21:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-29 16:20 Linking to libraries in the ELF? Maxime Devos
2021-03-09 21:04 ` Andy Wingo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).