bug reported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240717
> I got this error from compiling the kernel by using LLVM's ld for llvm80 and
> llvm70. I didn't try it with llvm60.
...
> (Reminder that I have already removed LLVM and linker from my base system).
kernel.full
ld.lld: err
Reported as bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240716
LD and XLD from make.conf are not working to set the linker. Softlink from
/usr/bin/ to chosen linker works in place of it.
___
freebsd-toolchain@freebsd.org mailing list
https://
> I got this error from compiling the kernel by using LLVM's ld for llvm80 and
> llvm70. I didn't try it with llvm60. It must be from newer LLVM ports'
> updates. (Reminder that I have already removed LLVM and linker from my base
> system).
kernel.full
ld.lld: error: unknown -z value: common-
Also, I didn't get this error for compiling my world. It seems specific to
kernel builds.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsu
I got this error from compiling the kernel by using LLVM's ld for llvm80 and
llvm70. I didn't try it with llvm60. It must be from newer LLVM ports' updates.
(Reminder that I have already removed LLVM and linker from my base system).
kernel.full
ld.lld: error: unknown -z value: common-page-size
d which I think will
> be sufficient for your use case.
>
> On Tue, Sep 03, 2019 at 11:04:08PM +0200, Sid wrote:
> > In /etc/make.conf, I have
> > LD= /usr/local/bin/ld.lld80
> >
> > This is not used for ports. It may be used for building the kernel and
>
> This is for FreeBSD 12.0. Older releases (since 11.2) have had similar
> problems to this one.
> I wouldn't be surprised if Stable and Current also have this problem,
> because of the common past issue with this that haven't been fully realized.
>
> Subject: linker not using make.conf
>
> In /et
In /etc/make.conf, I have
LD= /usr/local/bin/ld.lld80
This is not used for ports. It may be used for building the kernel and world.
clang-8: error: unable to execute command: Executable "ld" doesn't exist!
clang-8: error: linker command failed with exit code 1 (use -v to see
invocation)
***
m not sure if also has
to do with beyond the manpage description: if BINUTIL's can do without
installing objcopy, if elfcopy (as objcopy) is the default. Based your
response, maybe it is just a manpage concern.
Thank you for your response.
> Sent: Tuesday, September 11, 2018 at
Hi,
In src.conf, from 11.2 to 12-current, the elfcopy option was removed, but
objcopy still in the documentation for binutils. I suspect this is about the
toolchain too, and not only in the manpage for src.conf.
Should objcopy be removed from binutils and from the manpage too?
__
> Sent: Sunday, October 29, 2017 at 4:52 AM
> From: "Stefan Esser"
> To: Sid
> Subject: Re: External LLVM toolchain not consistently locating c++ when
> compiling ports
>
> Am 29.10.17 um 10:46 schrieb Sid:
> > Of course llvm50++ or llvm40++ as c++.
, October 29, 2017 at 2:48 AM
> From: "Mark Millard"
> To: Sid
> Cc: freebsd-toolchain@freebsd.org
> Subject: Re: External LLVM toolchain not consistently locating c++ when
> compiling ports
>
>
> On 2017-Oct-29, at 12:10 AM, Sid wrote:
>
> > This
it look in absolute locations for c++.
> Sent: Sunday, October 29, 2017 at 12:11 AM
> From: "Mark Millard"
> To: Sid
> Cc: freebsd-toolchain@freebsd.org
> Subject: Re: External LLVM toolchain not consistently locating c++ when
> compiling ports
>
>
> On 2017-Oct-2
In /etc/make.conf, when I use,
XCC=/usr/local/bin/clang40
XCXX= /usr/local/bin/clang++40
XCPP= /usr/local/bin/clang-cpp40
for ports that require c++ without clang in the base system, I get the error
code
make: "/usr/ports/Mk/Uses/compiler.mk" line 112:warning: "c++ -### /dev/null
2>&1
> wrote:
>> On Sat, Jul 15, 2017 at 23:34:37 UTC 2017, Sid wrote:
>> How about going with a toolchain directory for the base system only. It
>> would use shared files, and have subdirectories specific to clang, gcc, or
>> other compiling components or versions. This w
How about going with a toolchain directory for the base system only. It would
use shared files, and have subdirectories specific to clang, gcc, or other
compiling components or versions. This way it is both modular and organized.
For instance: /usr/toolchain/bin/, /usr/toolchain/sbin/, and
/usr
Any drastic change would have to be done in the head branch.
What about keeping ports' compilers as they are, by not using
/usr/local/toolchain/* at all.
Then going with the directory for the base system. For instance:
/usr/toolchain/bin/, /usr/toolchain/sbin/, and /usr/toolchain/lib/ for share
Hello,
Wouldn't it make sense for toolchains, compilers and their libraries to have
their own dedicated top level directories like something under /usr/toolchain/
and /usr/local/toolchain/ in the latest FreeBSD versions? It would be easier
for maintenance, and organization of compilers and tool
18 matches
Mail list logo
