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

CVS: some minor Win32-related problems #3436

Closed
vicuna opened this issue Jul 16, 2002 · 2 comments
Closed

CVS: some minor Win32-related problems #3436

vicuna opened this issue Jul 16, 2002 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 16, 2002

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

Bug description

Full_Name: Dmitry Bely
Version: CVS
OS: Windows 2000
Submission from: d088.p3.col.ru (195.210.132.88)

  1. config/Makefile.msvc:

TK_LINK=tk83.lib tcl83.lib

should be replaced with

TK_LINK=$(TK_ROOT)/lib/tk83.lib $(TK_ROOT)/lib/tcl83.lib

(as in config/Makefile.mingw)

  1. win32caml building is not included into root Makefile.nt. Also its Makefile
    is not adapted for MinGW build (only MSVC is supported).
@vicuna
Copy link
Author

vicuna commented Jul 17, 2002

Comment author: administrator

  1. config/Makefile.msvc:

TK_LINK=tk83.lib tcl83.lib

should be replaced with

TK_LINK=$(TK_ROOT)/lib/tk83.lib $(TK_ROOT)/lib/tcl83.lib

(as in config/Makefile.mingw)

I should put a comment here, as this is becoming a FAQ :-)
The lack of explicit prefixing is intentional: since we're
distributing binary builds of this port, the libraries should not
contain hard-wired paths such as $(TK_ROOT), because the end user may
have the TCL/TK libs installed elsewhere. Ergo, no absolute paths,
and both the builder and the user of OCaml should add the path to the
TCL/TK libs to the LIB environment variable, as explained in the
installation instructions.

  1. win32caml building is not included into root Makefile.nt. Also
    its Makefile is not adapted for MinGW build (only MSVC is
    supported).

Yes, I was lazy and didn't have the fortitude to translate the
Makefile :-)

All the best,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 18, 2002

Comment author: administrator

Xavier Leroy xavier.leroy@inria.fr writes:

  1. config/Makefile.msvc:

TK_LINK=tk83.lib tcl83.lib

should be replaced with

TK_LINK=$(TK_ROOT)/lib/tk83.lib $(TK_ROOT)/lib/tcl83.lib

(as in config/Makefile.mingw)

I should put a comment here, as this is becoming a FAQ :-)

Yes, you will cut caml/caml-bugs traffic dramatically and save a lot of
your time :-)

The lack of explicit prefixing is intentional: since we're
distributing binary builds of this port, the libraries should not
contain hard-wired paths such as $(TK_ROOT), because the end user may
have the TCL/TK libs installed elsewhere.

I see. When I would also remove the paths from config/Makefile.mingw,
making msvc/mingw configurations consistent. I have just discovered that
having -lfoo MinGW/Cygwin gcc (ld) searches for libfoo.a first and then (if
not found) for foo.lib. So,

TK_LINK=-Lc:/tcl/lib -ltk83 -ltcl83

or

LIBRARY_PATH=/cygdrive/c/tcl/lib
(somethere in the environment; in my case ld is Cygwin application
so /cygdrive seems to be required. For the native MinGW use
c:/tcl/lib)
TK_LINK=-ltk83 -ltcl83

would work. BTW, why not to distribute binaries of MinGW port?

Ergo, no absolute paths,
and both the builder and the user of OCaml should add the path to the
TCL/TK libs to the LIB environment variable, as explained in the
installation instructions.

  1. win32caml building is not included into root Makefile.nt. Also
    its Makefile is not adapted for MinGW build (only MSVC is
    supported).

Yes, I was lazy and didn't have the fortitude to translate the
Makefile :-)

I have made the necessary changes in win32caml/Makefile/.c files (but still
have a problem with MinGW-build ocamlwin.exe - the parent shell is closed
when it is started. Everything else works). Would you like to get a patch
when I fix that?

Hope to hear from you soon,
Dmitry

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