[m-rev.] for post-commit review: link/search/buildsys

Julien Fischer jfischer at opturion.com
Tue Jul 1 17:05:33 AEST 2025


On Tue, 1 Jul 2025 at 16:32, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> On Tue, 1 Jul 2025 11:09:08 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > On Mon, 30 Jun 2025 at 21:10, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> > Their only
> > use appears to be in compiler/link_target_code.m, which suggests that this
> > is *not* the case to me.
> >
> > In any case, I would suggest removing all references to the ml script above,
> > since all of those options are definitely used in the case where we invoke the
> > linker directly.
>
> Actually, by default, we pass those options neither to ml nor directly to the linker ld,
> but to gcc, which in turn will pass them to ld.
>
> It has been a very long time since I looked at this issue, but you may know the
> answer to the obvious question: is there any difference between the form
> in which you have to pass these options to gcc, and the form expected by ld?

Offhand, I don't know.  Note that Mercury *always* invokes the linker
via the C compiler driver (e.g. gcc or clang rather than ld, cl.exe
rather than link.exe).
In the context of these options it doesn't matter --ld-flags are the
flags passed to the
linker command (whatever it happens to be).

(I know that when linking Mercury programs against C++ generated object files,
g++ seems to insert all kinds of magic when it invokes that linker
that I wouldn't
want to reproduce by hand.)

> > The rest of the diff looks fine.
>
> Thank you. The attached diff addresses the issues you reported today,
> though it may need tweaking, depending on your answer to the question above.

That looks fine.

Julien.


More information about the reviews mailing list