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

I managed to link a hello world application, however the NetBSD-specific nits stand for production programs. RPATH is the first difference that matters. Unfortunately I'm swamped by other LLVM projects to join LLD.. research other differences and prepare patches myself. On 09.06.2017 00:11, Rui

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

I don't remember the details, but I believe LLD-generated executables are fine with either Linux or on NetBSD On Thu, Jun 8, 2017 at 3:08 PM, Kamil Rytarowski wrote: > On 08.06.2017 22:39, Rui Ueyama wrote: > > On Wed, Jun 7, 2017 at 6:55 AM, Joerg Sonnenberger via Phabricator > >

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

On 08.06.2017 22:39, Rui Ueyama wrote: > On Wed, Jun 7, 2017 at 6:55 AM, Joerg Sonnenberger via Phabricator > > wrote: > > joerg added a comment. > > In https://reviews.llvm.org/D33726#774105 >

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

On Wed, Jun 7, 2017 at 6:55 AM, Joerg Sonnenberger via Phabricator < revi...@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

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

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

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

krytarowski added a comment. I concur this, linkers are to used through a compiler frontend and `libtool` (which wraps a compiler). Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

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

ruiu added a comment. 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. For all OSes other than

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

krytarowski added a subscriber: ruiu. krytarowski added a comment. @ruiu what's your opinion on this? Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

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

joerg added a comment. A small subset can be found by searching for LINKER_RPATH_FLAG in pkgsrc. A classic offender is Emacs. For more, I would have to systematically search. Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits

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

krytarowski added a comment. What software in particular, besides compilers? Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

joerg added a comment. sysroot is already handled in NetBSD.cpp line 118 or so. Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

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

joerg added a comment. Such knowledge is necessary anyway. There is enough software that wants to use the linker directly. Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

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

krytarowski added a comment. Regardless of LLD, `--sysroot` is still needed I think. Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

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

atanasyan added a comment. In https://reviews.llvm.org/D33726#769301, @joerg wrote: > I'm against it. I consider this a strong bug on the LLD side and the behavior > of clang correct. Do you suggest to add knowledge about various OS (linux/*bsd) and arch (x86,arm,mips,...) specific paths to

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

joerg added a comment. I'm against it. I consider this a strong bug on the LLD side and the behavior of clang correct. Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

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

krytarowski added a comment. This works for me! Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

krytarowski added inline comments. Comment at: lib/Driver/ToolChains/NetBSD.cpp:324 : Generic_ELF(D, Triple, Args) { if (getDriver().UseStdLib) { // When targeting a 32-bit platform, try the special directory used on What's the rationale for this

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

krytarowski added a comment. Looks great! I'm going to test it. Repository: rL LLVM https://reviews.llvm.org/D33726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

atanasyan created this revision. This patch builds and passes `-L` arguments to the linker in case of NetBSD target. That makes possible to use LLD linker which does not have any built-in per-OS paths configuration. To do so the patch a) constructs paths to the library directories explicitly