[Caml-list] prelinking ocamlfind

[Caml-list] prelinking ocamlfind

[Leo Rozenberg]

Hello, all

I have noticed an odd behavior, between 3.07 and 3.08.0 versions of
ocaml. On otherwise identical systems of Fedora Core 1 distributions
(which by default prelinks libraries and executables daily), the
prelink command modifies ocamlfind built by 3.08 but not by 3.07.
This was concluded by examining the prelink log (prelink.log), which
is invoked with
/usr/sbin/prelink -av -mR -q

Another anomaly is the prelink cache witch stores the libraries and
their dependencies.
The cache (/etc/prelink.cache) is a binary, but one can get human
readable output with
/usr/sbin/prelink -p.

on the 3.08.0 system the relevant section of the cache is:
/usr/bin/ocamlfind:
    /lib/tls/libm-2.3.2.so [0x2db5504f]
    /lib/libdl-2.3.2.so [0xe9cd81da]
    /usr/lib/libncurses.so.5.3 [0xf3099bee]
    /lib/tls/libpthread-0.60.so [0x0b8fe91d]
    /lib/tls/libc-2.3.2.so [0xaa341c82]
    /lib/ld-2.3.2.so [0xe10ed221]
    /usr/lib/libgpm.so.1.19.0 [0xf249a779]

while the relevant section for the 3.07 (+2) system is:
/usr/bin/ocamlfind:
    /lib/tls/libm-2.3.2.so [0xabf1d043]
    /lib/libdl-2.3.2.so [0xe93b72e2]
    /lib/tls/libc-2.3.2.so [0x942cd696]
    /lib/ld-2.3.2.so [0x52ee8db5]

I am curious as to what might be the cause of this discrepancy.
Does anyone have any ideas?

Leonid

ps. I created a symbolic link to ocamlfind (in a different directory)
to stop it from being prelinked.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] prelinking ocamlfind

[Xavier Leroy]

> I have noticed an odd behavior, between 3.07 and 3.08.0 versions of
> ocaml. On otherwise identical systems of Fedora Core 1 distributions
> (which by default prelinks libraries and executables daily), the
> prelink command modifies ocamlfind built by 3.08 but not by 3.07.
> This was concluded by examining the prelink log (prelink.log), which
> is invoked with
> /usr/sbin/prelink -av -mR -q

I can't really explain the different behaviour between 3.07 and 3.08
(it seems to boil down to the fact that ocamlfind is linked with
different shared libraries in both cases, so maybe your two OCaml
installations were configured differently).

On a related not, I just wanted to mention that Fedora's prelinking
breaks mixed-mode executables generated by "ocamlc -custom", rendering
them unusable.  The reason is that prelinking removes the bytecode
part of these mixed-mode executables, just like "strip" does.

Fortunately, "ocamlc -custom" is no longer very useful since dynamic
loading of C libraries can be used instead (and produces a pure
bytecode executable that is left undisturbed by prelinking).

Nonetheless, some old Makefiles still contain "ocamlc -custom" where
"ocamlc" would suffice, and this can lead to problems with Fedora's
prelinking.  (Example: the "coqtop" command from the Coq proof assistant.)
Keep this in mind...

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] prelinking ocamlfind

[Sven Luther]

On Fri, Jul 16, 2004 at 04:47:02PM +0200, Xavier Leroy wrote:
> > I have noticed an odd behavior, between 3.07 and 3.08.0 versions of
> > ocaml. On otherwise identical systems of Fedora Core 1 distributions
> > (which by default prelinks libraries and executables daily), the
> > prelink command modifies ocamlfind built by 3.08 but not by 3.07.
> > This was concluded by examining the prelink log (prelink.log), which
> > is invoked with
> > /usr/sbin/prelink -av -mR -q
> 
> I can't really explain the different behaviour between 3.07 and 3.08
> (it seems to boil down to the fact that ocamlfind is linked with
> different shared libraries in both cases, so maybe your two OCaml
> installations were configured differently).
> 
> On a related not, I just wanted to mention that Fedora's prelinking
> breaks mixed-mode executables generated by "ocamlc -custom", rendering
> them unusable.  The reason is that prelinking removes the bytecode
> part of these mixed-mode executables, just like "strip" does.

Xavier, i have been told that this probably happens because we use a elf
section that is normally strippable. It could be solved by using a
special elf section specialized to our need (maybe one named bytecode or
something), then at least strip and possibly the prelink stuff, would
not remove it as it does not.

Now, i am not elf knowledgeable, but i suppose this may break backward
compatibility of ocaml code or something. See here for the later debian
bug report, but there was some other discussion of this earlier i don't
remember :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900

Friendly,

Sven Luther

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] prelinking ocamlfind

[Xavier Leroy]

> Xavier, i have been told that this probably happens because we use a elf
> section that is normally strippable.

It's even worse than that, but I won't get into details :-)

> It could be solved by using a
> special elf section specialized to our need (maybe one named bytecode or
> something), then at least strip and possibly the prelink stuff, would
> not remove it as it does not.

Yes, but:
- This solution is not portable to non-ELF platforms (e.g. MS Windows),
  thus forcing an unpleasant fork in the code.
- The ELF format is very complex.  There are libraries that facilitate
  manipulations of ELF files (e.g. libelf), but these are not
  universally available and severely under-documented.

Rather than muck with ELF, a simpler solution would be to embed the
bytecode executable as initialized C arrays in the executable
generated by ocamlc -custom.  That's what ocamlc -output-obj does, and
I believe it shouldn't be too hard to adapt the existing -output-obj
code to the -custom case.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] prelinking ocamlfind

[Sven Luther]

On Mon, Jul 19, 2004 at 03:48:46PM +0200, Xavier Leroy wrote:
> > Xavier, i have been told that this probably happens because we use a elf
> > section that is normally strippable.
> 
> It's even worse than that, but I won't get into details :-)

Hehe.

> > It could be solved by using a
> > special elf section specialized to our need (maybe one named bytecode or
> > something), then at least strip and possibly the prelink stuff, would
> > not remove it as it does not.
> 
> Yes, but:
> - This solution is not portable to non-ELF platforms (e.g. MS Windows),
>   thus forcing an unpleasant fork in the code.
> - The ELF format is very complex.  There are libraries that facilitate
>   manipulations of ELF files (e.g. libelf), but these are not
>   universally available and severely under-documented.
> 
> Rather than muck with ELF, a simpler solution would be to embed the
> bytecode executable as initialized C arrays in the executable
> generated by ocamlc -custom.  That's what ocamlc -output-obj does, and
> I believe it shouldn't be too hard to adapt the existing -output-obj
> code to the -custom case.

Mmm. Ok, it will be ocaml 3.09 stuff though.

CCing this to the relevant debian bug report. 

Friendly,

Sven Luther

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners