Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linker bug? #2400

Closed
vicuna opened this issue Mar 18, 2000 · 3 comments
Closed

linker bug? #2400

vicuna opened this issue Mar 18, 2000 · 3 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Mar 18, 2000

Original bug ID: 61
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Markus Mottl
Version: 2.99+12
OS: Digital Unix 4.0e / Alpha
Submission from: alford.dai.ed.ac.uk (129.215.25.74)

Hello,

there seems to be a strange bug with the linker, which effects
at least ocamlmktop and ocamlopt.opt (seems to be ok with ocamlc.opt

  • I have not tried the byte code versions):

The following program (makes use of my PCRE-lib - works with
OCaml 2.99):

open Unix;;
let f () = Pcre.version

behaves strangely when I try to link it (native code) or when I want
to have it interpreted (independent of the specific PCRE-function).

When I link it with ocamlopt.opt, I get the following:

ocamlopt.opt -I {longlibpath} -ccopt -L {longlibpath} -cclib -lpcre pcre.cmxa
-o bla bla.cmx
ld:
Can't open: pcre_intf.o (No such file or directory)

I have not linked in the unix library here (line even longer),
but the result is the same and also then when I leave away
the line containing "open Unix". But...

When I try to interpret it with "mocaml", which I have created
with "ocamlmktop" (also always worked), I get the following
message:

Uncaught exception: Invalid_argument("String.get")

However, if I delete the line containing "open Unix" and
interpret the file with the same toplevel, it works! - It
also runs fine, when the program really does something
interesting with the PCRE-library (as long as I do not
reference the Unix-library somehow)...

Furthermore, when I compile the file with "ocamlc.opt",
the resulting executable works either way (with or without
the "open Unix"-line). Only when I really use a function
from "Unix" do I have to link in the unix-library, which
also works as expected.

So in short: everything (as far as I could see) works fine
with "ocamlc.opt" - but I get an unexpected link error from
ocamlopt.opt and "ocamlmktop" generates a toplevel that
does not behave correctly.

Here, there is another interesting aspect to note:

I normally link in many libraries into "mocaml". When I
leave some of them away, it may be that the above example
immediately works, behaves as before, or issues another
error message like:

File "bla.ml", line 2, characters 11-23:
Unbound value Pcre.version

I have not found out, how the linkage order really
influences behaviour: this seems pretty non-deterministic.
It also seems that the strange behaviour with the toplevel
only appears when I use "open Unix" - not when I leave it
away or open another library (e.g. Str).

That's all I can say so far. I have built my PCRE-library
twice and made sure that its files are where they normally
reside, but the problem did not disappear - maybe
I have overlooked something trivial?

In case you need it for finding the bug (or otherwise ;-),
here the link to my pcre-distribution:

http://miss.wu-wien.ac.at/~mottl/ocaml_sources/intro.html

and take "pcre_ocaml.tar.gz"...

Ah, before I forget: I had to modify a Makefile during the
build process of ocaml (should be independent of upper problem):
the labltk-library (otherlibs/labltk/support) linked with the
option "-label". Since I luckily read the mailing list, I knew
that this should mean "-modern" and changed it appropriately
(the change has obviously not yet made it into the distribution)...

Best regards,
Markus Mottl

@vicuna
Copy link
Author

vicuna commented Mar 29, 2000

Comment author: administrator

there seems to be a strange bug with the linker, which effects
at least ocamlmktop and ocamlopt.opt (seems to be ok with ocamlc.opt

  • I have not tried the byte code versions):
    The following program (makes use of my PCRE-lib - works with
    OCaml 2.99):
    open Unix;;
    let f () = Pcre.version
    behaves strangely when I try to link it (native code) or when I want
    to have it interpreted (independent of the specific PCRE-function).
    When I link it with ocamlopt.opt, I get the following:
    ocamlopt.opt -I {longlibpath} -ccopt -L {longlibpath} -cclib -lpcre pcre.cmxa
    -o bla bla.cmx
    ld:
    Can't open: pcre_intf.o (No such file or directory)

I can explain this one. The behavior of ocamlc -a and ocamlopt -a
changed recently, so as to "remember" the -custom flag, as well as C
libraries and options specified on the command line, in the library
file created. Those flags are then automatically added when linking
with that library file. In other terms, you can now do

    ocamlc -a -o mylib.cma -custom -cclib -lmylib mylib.cmo

and later
ocamlc mylib.cma <other .cmo and .cma files>

instead of, as before,

    ocamlc -a -o mylib.cma mylib.cmo

and later
ocamlc -custom mylib.cma <other .cmo and .cma files> -cclib -lmylib

This should simplify Makefiles quite a lot, as well as making the
transition to dynamic loading of C libraries easier in a future
release.

Now, your pcre.cmxa library is created with

    ocamlopt -a -I ../pcre-C pcre_intf.o -o pcre.cmxa pcre.cmx

Before, pcre_intf.o was simply ignored. Now, it's remembered in the
pcre.cmxa file and added at every link involving that library, which
causes the error you saw.

When I try to interpret it with "mocaml", which I have created
with "ocamlmktop" (also always worked), I get the following
message:
Uncaught exception: Invalid_argument("String.get")

I haven't been able to reproduce this behavior. How do you create mocaml?
I created it with ocamlmktop unix.cma pcre.cma ... Then,
mocaml bla.ml worked OK.

Best regards,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Mar 30, 2000

Comment author: administrator

Unfortunately, this problem still persists. Here more details on it - I
managed to find an example that should more clearly demonstrate its
weirdness:

OK, we were able to reproduce the problem and (after a couple of hours
under gdb) understand it. You've uncovered a rather subtle GC bug in the
Obj.truncate function, which the OCaml toplevel uses to shorten the
argument vector when interpreting a script. Congratulations for
(unwillingly) finding it!

However, we found an (unrelated) error in your PCRE wrappers: in
function pcre_firstchar_wrapper, you allocate a variant with argument
as follows:

  v_firstchar = alloc_small(1, 748194550);
  Field(v_firstchar, 1) = Val_int(firstchar);

which should be:

  v_firstchar = alloc_small(2, 0);
  Field(v_firstchar, 0) = Val_int(748194550);
  Field(v_firstchar, 1) = Val_int(firstchar);

I'll see with Jacques if we can provide a macro in mlvalues.h that
computes the hash value of a variant tag. If that cannot be done, I'd
recommend registering variants from Caml and extract the tags from C,
so that you don't have to hard-wire their hash values.

Yet another remark: in your first call to alloc_final, the 1 / 10
ratio seem a bit low. It's not a bug, but it means that the major GC
is going to work unnecessarily hard: you're forcing the major GC to do
a full cycle at least every 10 regexps allocated. You may consider
using a ratio of 1 / 100 or less. However, had you not forced the
major GC to work that hard, you probably wouldn't have uncovered the
GC bug...

Keep up finding those subtle bugs!

All the best,

  • Xavier Leroy and Damien Doligez

@vicuna
Copy link
Author

vicuna commented Mar 30, 2000

Comment author: administrator

J'ai fixe le probleme avec -label / -modern -- Damien.
Premier probleme OK (changement de semantique de ocamlopt -a) -- Xavier
Second probleme corrige 2000-03-30 -- Xavier & Damien

@vicuna vicuna closed this as completed Mar 30, 2000
@vicuna vicuna mentioned this issue Mar 14, 2019
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant