apparent bug: 'invalid ELF header'

[o-jasper]

julia> libc = dlopen("libc")
/usr/lib/libc.so: invalid ELF header
could not load module libc
 in dlopen at /home/jasper/oproj/programs/julia/j/base.j:97

I am in version 3458255(...) on (64 bit)Arch Linux. Glibc version 2.15-6. Other libraries, like libnova do seem to work. Bit of a bummer that it is exactly the one from the example to break. Tried to grab another libc.so, to see if it but failed(accidentally got 32, file wont open)

The functions of regex.h are in there right? I wanted to make destructuring-regex(as i wrote for Common Lisp), but for julia. (Basically, the idea is that results and what is between results go straight into variables.)

[JeffBezanson]

I've found that in many linux distros libc.so is actually a linker script, and the dynamic linker locates this as the library but is not able to use it! This is very frustrating. Fortunately, julia is already linked against libc so the symbols are available in the "default" library via ccall(:getpid, ...) etc.

We have a regex library using pcre (j/regex.j); you will probably want to use those functions in some way.

[StefanKarpinski]

Let's have a discussion of what you're thinking with the regex business. What we have now is serviceable and certainly no worse than what's in various scripting languages, but a better design could certainly be quite possible.

[StefanKarpinski]

I think the dev list is probably a good place for such a discussion.

[o-jasper]

I'll poke around a bit and see if i can make an analogous destructuring-regex and post to the dev list then.(though the name should probably be more descriptive.)

Ok that the issue is closed, but maybe change the error message for the things Julia is already linked against?

[JeffBezanson]

We could parse the linker script ourselves to find the real file name. It seems absurd that applications would all need to implement this logic. Obviously the linker script thing is a half-implemented feature.
For reference, here is a patch to GHC that implements this feature:

http://hackage.haskell.org/trac/ghc/attachment/ticket/2615/T2615a.dsend

[JeffBezanson]

Probably good to remove most of src/dlload.c and implement dlopen in julia for easier parsing.

[o-jasper]

@StefanKarpinski i posted on the mailing list about it. Goodnight&have a nice weekend. Update: forked it, and updated, of which julia/j/regex.j contains a newer version of the macro.

[ViralBShah]

@JeffBezanson Can src/dlload.c be moved to julia without any bootstrapping issues. Would loading it early enough in sysimg.j be good enough?

[ViralBShah]

Doesn't propose a solution, but discusses the problem. Can we run the script /lib and figure where the real version is, and then load that?

http://askubuntu.com/questions/40416/why-is-lib-libc-so-6-missing

[JeffBezanson]

AFAIK all you can do is parse the thing yourself, it's not executable or anything.

[ViralBShah]

How does gcc do it?

-viral

On 10-Mar-2012, at 11:29 PM, JeffBezansonreply@reply.github.com wrote:

AFAIK all you can do is parse the thing yourself, it's not executable or anything.

---

Reply to this email directly or view it on GitHub:
#450 (comment)

[ViralBShah]

I believe ldconfig does the work in identifying the right thing.

-viral

On 10-Mar-2012, at 11:29 PM, JeffBezansonreply@reply.github.com wrote:

AFAIK all you can do is parse the thing yourself, it's not executable or anything.

---

Reply to this email directly or view it on GitHub:
#450 (comment)

[JeffBezanson]

But is there any way we can take advantage of that functionality?

[ViralBShah]

Douglas Bates wrote to a debian dev, who said he doesn't know himself. The suggestion was to write to debian-devel.

-viral

On 11-Mar-2012, at 8:16 AM, JeffBezansonreply@reply.github.com wrote:

But is there any way we can take advantage of that functionality?

---

Reply to this email directly or view it on GitHub:
#450 (comment)

[nolta]

Seems like it might be doable:

nolta@ubuntu1110:~/julia$ ldconfig -p | grep libc.so
    libc.so.6 (libc6, OS ABI: Linux 2.6.15) => /lib/i386-linux-gnu/libc.so.6
nolta@ubuntu1110:~/julia$ ./julia
               _
   _       _ _(_)_     |
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  A fresh approach to technical computing
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.0.0+1331430882.r69af
 _/ |\__'_|_|_|\__'_|  |  Commit 69afb7032d (2012-03-10 20:54:42)
|__/                   |

julia> x = dlopen("/lib/i386-linux-gnu/libc.so.6")
Ptr{Void} @0xb783ab08

[nolta]

extras/openlib.jl appears to fix this problem.

[staticfloat]

Confirmed, the following works on both my OSX 10.8.2 x86_64 laptop and my Linux i386 VM:

julia> require("extras/openlib.jl")

julia> Openlib.openlib("libc")
Ptr{Void} @0x00007f94ed2adc00

[grep0]

Still an issue after 6 years

julia> ccall((:clock, :libc), Int32, ())
ERROR: error compiling top-level scope: could not load library "libc"
/usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header
julia> ccall((:clock, "/lib/x86_64-linux-gnu/libc.so.6"), Int32, ())
1000525

Debian 4.17 x86_64

[yuyichao]

This is now intentional

[pengwyn]

If this is intentional then perhaps a different example in the docs (https://docs.julialang.org/en/v1/manual/calling-c-and-fortran-code/) might be needed? Or perhaps those examples (for :clock, :getent, :gethostname) should remove the "libc" part of their calls with an explanation for why that is needed.

[introspection3]

is fatal bug!!!! centos ERROR: error compiling top-level scope: could not load library "libc"

[introspection3]

when and how to solve this bug

[introspection3]

v1.0 v.11

[StefanKarpinski]

Please post questions to the Julia discourse discussion forum.