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?