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

ocamlopt 3.01 on win32 (msvc) requires *.lib with *.cmxa #2864

Closed
vicuna opened this issue Jul 28, 2001 · 2 comments
Closed

ocamlopt 3.01 on win32 (msvc) requires *.lib with *.cmxa #2864

vicuna opened this issue Jul 28, 2001 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 28, 2001

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

Bug description

Two related bugs:

  1. I'm trying to compile a project with a foo.cmxa file that was generated without any .ml files, so there's no object code. I do have a .mli interface and a separate bar.lib C implementation library. I can build the foo.cmxa fine, but when I go for the final link, ocamlopt ... foo.cmxa ... causes a linker error (in msvc's link.exe), complaining that there's no foo.lib to go along with the foo.cmxa. foo.cmxa does not seem to reference a foo.lib internally, so this seems to be something ocamlopt is adding?

If I create an empty dummy foo.lib, the project links fine.

  1. If there's a foo.lib existing when foo.cmxa (the library without any objects) is built, the original gets erased. This means I need to name the C implementation file something completely different so that the ocamlopt -a doesn't delete it.

Chris

@vicuna
Copy link
Author

vicuna commented Jul 30, 2001

Comment author: administrator

  1. I'm trying to compile a project with a foo.cmxa file that was
    generated without any .ml files, so there's no object code. I do
    have a .mli interface and a separate bar.lib C implementation
    library. I can build the foo.cmxa fine, but when I go for the final
    link, ocamlopt ... foo.cmxa ... causes a linker error (in msvc's
    link.exe), complaining that there's no foo.lib to go along with the
    foo.cmxa. foo.cmxa does not seem to reference a foo.lib internally,
    so this seems to be something ocamlopt is adding?

Yes. Normally, for each .ml file, ocamlopt produces both a .cmx file
(compilation info) and a .obj file (the actual code), and ocamlopt -a
produces both a .cmxa file (compilation info for the library) and
a .lib file (the actual library file containing the code). The .lib
file is built by calling Microsoft's LIB program, but apparently it
refuses to create an empty library. (The Unix "ar" program that is
called for the same purposes has no problems with that.)

The LIB documentation doesn't indicate any way to change this
behavior. I'd recommend making the .cmxa non empty, by having .ml
files that implement the .mli files associated with your library.
I understand that in simple cases the .ml files will be just copies of
the .mli files, containing only type and external declarations.
Experience shows however that it rarely remains so, and often some
initialization code needs to be added to the library, resulting in
non-trivial .ml files. So, consider this as an investment for the
future :-)

  1. If there's a foo.lib existing when foo.cmxa (the library without
    any objects) is built, the original gets erased.

This is normal: ocamlopt -a erases foo.lib in preparation for
rebuilding it using LIB. It's just that LIB doesn't do its part of
the job :-)

This means I need
to name the C implementation file something completely different so
that the ocamlopt -a doesn't delete it.

It is recommended procedure anyway: the library containing the code
for the C part of your library should be named differently than that
generated by ocamlopt -a, which contains code for the Caml part.

Best wishes,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 31, 2001

Comment author: administrator

LIB lossage w.r.t. empty libraries.

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