[m-rev.] for post-commit review: classify oc_link options by target language

[Zoltan Somogyi]

On Fri, 13 Jun 2025 11:59:42 +1000, Peter Wang <novalazy at gmail.com> wrote:

> On Thu, 12 Jun 2025 23:05:34 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > For review by anyone.
> > 
> > The diff to handle_options.m points out what may be a bug, but I cannot tell,
> > because the only effect is on the value of an option whose meaning I don't understand:
> > default_runtime_library_directory. Does anyone else know?
> 
> --no-default-runtime-library-directory prevents the compiler adding any
> directories to the runtime search path automatically. You can see the
> RUNPATH/RPATH that gets embedded into a binary with (on Linux):
>     objdump -x $binary | grep 'R.*PATH'
> 
> If you are distributing dynamically linked binaries to the world,
> you probably don't want the binary to be searching for shared libraries
> in locations specific to YOUR machine.
> 
> > The obvious fix is
> > to switch the order of the two calls involved, but my guess iis that if that happens
> > to be wrong, we don't have an automatic test catch it. Can anyone confirm or
> > deny that?
> 
> If I understood properly, the bug you mention could occur in this situation:
> 
> In handle_directory_options, if mercury_linkage = "static",
> then standard library directories are NOT added to
> runtime_link_library_directories, and default_runtime_library_directory
> is also forced to 'no'.
> 
> In handle_target_compile_link_symlink_options,
> if shared_lib_not_executable = yes, then linkage and mercury_linkage
> will be set to "shared". But no libraries will be have been added to
> runtime_link_library_directories, even if
> default_runtime_library_directory was originally 'yes'.
> 
> --compile-to-shared-lib (shared_lib_not_executable) is an undocumented
> option only used to implement interactive queries in the debugger.
> The debugger doesn't pass --mercury-linkage static at the same time
> (obviously, since it is trying to build a shared library),
> so the bug should never arise in practice.
> 
> As for a fix, I think we just need to move the shared_lib_not_executable
> implications before handle_directory_options?

The attached diff does this.

Zoltan.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.ml
Type: application/octet-stream
Size: 39 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20250613/708eb4fb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.ml
Type: application/octet-stream
Size: 2073 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20250613/708eb4fb/attachment-0001.obj>