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 error w/MS VC++ Toolkit 2003 #3333

Closed
vicuna opened this issue Dec 4, 2004 · 1 comment
Closed

Linker error w/MS VC++ Toolkit 2003 #3333

vicuna opened this issue Dec 4, 2004 · 1 comment
Labels

Comments

@vicuna
Copy link

vicuna commented Dec 4, 2004

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

Bug description

Full_Name: Sachin Shah
Version: 3.08.2
OS: Windows XP SP2
Submission from: adsl-68-123-9-55.dsl.pltn13.pacbell.net (68.123.9.55)

In order to compile the program, the following applications need to be
installed:

(1) Cygwin with 'make' installed
(2) Microsoft .NET Framework 1.1
(3) Microsoft .NET Framework SDK 1.1
(4) Microsoft Platform SDK (Windows XP SP2) (2600.2180)
(5) Microsoft Visual C++ Toolkit 2003
(6) Microsoft Visual C++ 6.0 Processor Pack (all you need is ml.exe and ml.err.
You can extract these by unpacking vcpp5.exe using WinRAR or any other CAB
extraction program)
(7) Microsoft Help Workshop

NOTE: I also compiled my own Tcl/TK libraries, so you might not need the MS
Platform SDK [4]. However, it doesn't hurt anything.

You will have to create a 'lib' executable and put it in your path. I used
lib.bat, which is as follows:

@echo off
if "%1" == "" goto nocmd
echo %* > cmdline.tmp
link /lib @cmdline.tmp
del cmdline.tmp
goto end
:nocmd
link /lib
:end

I followed the instructions in Readme.win32. I edited config/Makefile to point
to the correct Tcl/TK library path and started compiling. 'make -f Makefile.nt
world' and 'make -f Makefile.nt bootstrap' run without a problem.

The problem came up during the command 'make -f Makefile.nt opt'. During this
command, while in the stdlib directory, make tries to compile the 'allopt'
target, which leads down to the 'stdlib.cmxa' and 'std_exit.cmx' files. While
compiling stdlib.cmxa, it tries to compile stdlib.lib. Here is the error I
get:
================================ (extra lines added for clarity)
../boot/ocamlrun ../ocamlopt -a -o stdlib.cmxa pervasives.cmx
array.cmx list.cmx char.cmx string.cmx sys.cmx hashtbl.cmx sort.cmx
marshal.cmx obj.cmx int32.cmxint64.cmx nativeint.cmx lexing.cmx
parsing.cmx set.cmx map.cmx stack.cmx queue.cmx stream.cmx buffer.cmx
printf.cmx format.cmx scanf.cmx arg.cmx printexc.cmx gc.cmx
digest.cmx random.cmx callback.cmx camlinternalOO.cmx oo.cmx
genlex.cmx weak.cmx lazy.cmx filename.cmx complex.cmx arrayLabels.cmx
listLabels.cmx stringLabels.cmx moreLabels.cmx stdLabels.cmx

LINK : fatal error LNK1104: cannot open file '@c:\DOCUME1
\sachin\LOCALS
1\Temp\camlrespfba3be'

../boot/ocamlrun ../ocamlopt -warn-error A -nostdlib ./Compflags std_exit.cmx -c std_exit.ml

As you can see, make does not stop for this, but keeps going on to std_exit.cmx.
However, this is a problem when running the command 'make -f Makefile.nt
install', since that command depends on stdlib.lib.

Here is a patch that was suggested to me by Dmitry Grebeniuk from the
ocaml_beginners groups on Yahoo!. It is as follows:

--- utils\ccomp.ml Fri Jun 25 17:08:02 2004
+++ utils\ccomp.ml Fri Jun 25 18:41:08 2004
@@ -42,9 +42,9 @@
let s =
String.concat " "
(List.map (fun f -> if f = "" then f else Filename.quote f) lst) in

  • if Sys.os_type = "Win32" && String.length s >= 256
  • (*if Sys.os_type = "Win32" && String.length s >= 256
    then build_diversion lst
  • else s
  • else*) s

let compile_file name =
match Config.ccomp_type with

From what I can tell, the "build_diversion lst" is used because long command
lines are a problem on Win32. However, the new linker does not have this
problem. In fact, it cannot find the list (I'm not even sure what it is
building) created by 'build_diversion lst' and simply dies.

Admittedly, I have no idea how other compilation environments on Win32 (cygwin,
mingw32, ...) are affected by this change. However, it fixes the problem in the
environment I have described above.

Best regards,

Sachin.

@vicuna
Copy link
Author

vicuna commented Feb 2, 2005

Comment author: administrator

Observed behavior is due to the lib.bat script inserted by the user. Attempted
fix: use "link /lib" instead of "lib" for MSVC port. XL, 2004-02-02

@vicuna vicuna closed this as completed Feb 2, 2005
@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