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

Re: ocamlopt 3.01 on win32 (msvc) requires *.lib with *.cmxa (PR#456) #2874

Closed
vicuna opened this issue Jul 30, 2001 · 1 comment
Closed
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 30, 2001

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

Bug description

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.)

Yeah, I initially worked around it by having something like this in my make rule:

echo. > foo.c
cl -c foo.c
lib /out:foo.lib foo.obj
rm -f foo.c foo.obj

I decided that was totally lame, and just copied the mli file into the ml file. Of course, that brings up one of my other issues with ocaml (the fact that you have to copy the mli file contents if you've got an ml file), but we've talked about that on caml-list and I suppose you wouldn't consider that a bug. :)

You might think about having the ocamlopt -a pass make the dummy .c file for compatibility with unix, since you can do the right thing with tmp names and whatnot. Maybe it's not worth it. If you point me to the code I could probably do it, but a cursory glance didn't show me where the magic happens from .cmxa -> .lib.

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.

This would be a good one for the tools documentation.

Thanks, and congrats on 3.02!

Chris

@vicuna
Copy link
Author

vicuna commented Jul 31, 2001

Comment author: administrator

See #2864

@vicuna vicuna closed this as completed Jul 31, 2001
@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