[PATCH] D33726: [driver][netbsd] Build and pass `-L` arguments to the linker

Rui Ueyama via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 8 13:39:07 PDT 2017


On Wed, Jun 7, 2017 at 6:55 AM, Joerg Sonnenberger via Phabricator <
reviews at reviews.llvm.org> wrote:

> joerg added a comment.
>
> In https://reviews.llvm.org/D33726#774105, @ruiu wrote:
>
> > I'm totally against adding per-OS path knowledge to our linker.
> Compilers already know include paths and I don't want to maintain another
> list of paths in the linker. Also this can be more confusing than useful
> when you are doing cross-linking.
>
>
> The only reason for compilers to maintain that list is for finding crt*.o.
> They otherwise don't care about the library paths at all. There is no
> confusion for cross-linking as long as proper sysroot support is used.
> Which we have been doing on NetBSD for ages.


That's not what clang is trying to do for all Unix-like systems (except
NetBSD due to the bug), right? The compiler driver actually passes library
paths to the linker. If you think that is wrong, you should make a change
to stop doing that on all systems. I don't see a reason to not do this only
on NetBSD.

> For all OSes other than NetBSD, LLD works fine with the clang driver as
> the driver passes include paths to the linker. I don't see any reason not
> to do the same thing for NetBSD. That stands even if the linker has to have
> a list of include paths.
>
> Sorry, but this is again ignorant and wrong. The very same problem of
> build systems calling ld directly apply on most other systems. Even then,
> the list of linker paths is not the only OS-specific knowledge. Things like
> the DT_RPATH vs DT_RUNPATH mess, init vs init_array all belong into this
> category. The list goes on.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D33726
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170608/de1b487b/attachment.html>


More information about the cfe-commits mailing list