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

ocamlmklib always adds -L (absolute) directories also the run-time linker path. #5943

Closed
vicuna opened this issue Mar 12, 2013 · 2 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Mar 12, 2013

Original bug ID: 5943
Reporter: is
Status: acknowledged (set by @damiendoligez on 2013-06-19T18:34:33Z)
Resolution: open
Priority: high
Severity: minor
Platform: any
OS: any
OS Version: any
Version: 4.00.1
Category: tools (ocaml{lex,yacc,dep,debug,...})
Tags: patch
Monitored by: is @ygrek @hcarty

Bug description

ocamlmklib contains this snippet:

else if starts_with s "-L" then
 (c_Lopts := s :: !c_Lopts;
  let l = chop_prefix s "-L" in
  if not (Filename.is_relative l) then rpath := l :: !rpath)

This results in absolute paths always added to the run-time-path. This is wrong in any build environment where the object directory is accessed through an absolute path; when using -R, the wrong path is added along the right one.

Contrary, ELF linker tools always require explicit specification of the run-time path, even when the same.

I suggest removing
let l = chop_prefix s "-L" in
if not (Filename.is_relative l) then rpath := l :: !rpath)

If this behaviour is deemed necessary for backwards compatibility, the new one should at least be selectable by a global option to ocamlmklib.

File attachments

@vicuna
Copy link
Author

vicuna commented Mar 13, 2013

Comment author: is

remove those two lines and the ( before c_Lopts :=, of course.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant