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? #2401

Closed
vicuna opened this issue Mar 18, 2000 · 1 comment
Closed

linker bug? #2401

vicuna opened this issue Mar 18, 2000 · 1 comment
Labels

Comments

@vicuna
Copy link

vicuna commented Mar 18, 2000

Original bug ID: 62
Reporter: administrator
Status: closed
Resolution: not a bug
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

Double emploi avec #2400

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