> What is the right way to build with gcc?
Here is one data point.
> exa% MAKEOBJDIRPREFIX=/tmp/obj/ make -j 16 -s buildworld
> __MAKE_CONF=/dev/null SRCCONF=/dev/null TARGET=amd64 TARGET_ARCH=amd64
> CROSS_TOOLCHAIN=amd64-gcc14
With a not-that-recent stable/14 (based on 6f34788
On 5/16/24 4:05 PM, Lorenzo Salvadore wrote:
On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov
wrote:
gcc13 from ports
`# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3 fini 4
fini 5 fini 2 fini 1`
The above order is not expected. I think clang&
> On May 17, 2024, at 2:26 AM, Konstantin Belousov wrote:
>
> On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote:
>> Hi,
>>
>> I'm recently working on https://reviews.freebsd.org/D45194 and got noticed
>> that gcc behaves weirdly.
>>
On Thu, May 16, 2024 at 08:05:57PM +, Lorenzo Salvadore wrote:
> On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov
> wrote:
> > > gcc13 from ports
> > > `# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3
> > > fini 4 fin
On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov
wrote:
> > gcc13 from ports
> > `# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3
> > fini 4 fini 5 fini 2 fini 1`
> >
> > The above order is not expected. I think clang'
On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote:
> Hi,
>
> I'm recently working on https://reviews.freebsd.org/D45194 and got noticed
> that gcc behaves weirdly.
>
> A simple source file to demonstrate that.
>
> ```
> # cat ctors.c
>
> #in
Hi,
I'm recently working on https://reviews.freebsd.org/D45194 and got noticed
that gcc behaves weirdly.
A simple source file to demonstrate that.
```
# cat ctors.c
#include
__attribute__((constructor(101))) void init_101() { puts("init 1"); }
__attribute__((constructo
From: Yasuhiro Kimura
Subject: Re: Buildworld fails with external GCC toolchain
Date: Tue, 15 Feb 2022 08:26:00 +0900 (JST)
>> I have amd64 world + kernel building with GCC 9 and the only remaining
>> open review not merged yet is https://reviews.freebsd.org/D34147.
>>
>&g
From: John Baldwin
Subject: Re: Buildworld fails with external GCC toolchain
Date: Mon, 14 Feb 2022 10:46:29 -0800
>>> Not really, the gcc 9 build has been broken for months, as far as I
>>> know.
>>>
>>> See also: https://ci.freebsd.org/job/FreeBSD-main-amd6
On 2/12/22 11:34 AM, Yasuhiro Kimura wrote:
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
Not really, the gcc 9 build has been broken for months, as far as I know.
See also: https://ci.freebsd.org/job/FreeBSD-main-amd64
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
> Not really, the gcc 9 build has been broken for months, as far as I know.
>
> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
>
> The last
On 11 Feb 2022, at 21:07, Yasuhiro Kimura wrote:
>
> I'm tring to update devel/binutils port to 2.38. When it was updated
> to 2.37.1, there was a suggestion that it should also be checked if
> building base system with GCC succeeds as binutils is a part of
> external GCC to
Hello,
I'm tring to update devel/binutils port to 2.38. When it was updated
to 2.37.1, there was a suggestion that it should also be checked if
building base system with GCC succeeds as binutils is a part of
external GCC toolchain. So I'd like to do it with binutils 2.38 before
updatin
QUOTE from man src.conf :
To be able to build the system, either gcc
or clang bootstrap must be enabled unless an alternate compiler
is provided via XCC.
END QUOTE
QUOTE from man src.conf :
The CCACHE_COMPILERCHECK
option defaults to content when using
gt; void *p;
> >>
> >> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
> >> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
> >> printf("p= %p\n", p);
> >> return (0);
> >> }
> >
ain(void)
>> {
>> void *p;
>>
>> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
>> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
>> printf("p= %p\n", p);
>> return (0);
>> }
>>
>> O
oid *)0x2000, 0x100, PROT_READ | PROT_WRITE |
> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
> >> printf("p= %p\n", p);
> >> return (0);
> >> }
> >>
> >> On i386 the following happens:
> >> * when compiling it with cc and
ain(void)
>> {
>> void *p;
>>
>> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
>> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
>> printf("p= %p\n", p);
>> return (0);
>> }
>>
>> O
D | PROT_WRITE |
> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
> printf("p= %p\n", p);
> return (0);
> }
>
> On i386 the following happens:
> * when compiling it with cc and running it, it crashes.
> * when compiling it with gcc it runs fine.
&
return (0);
}
On i386 the following happens:
* when compiling it with cc and running it, it crashes.
* when compiling it with gcc it runs fine.
On amd64 the following happens:
* when compiling it with cc -m64 it runs fine.
* when compiling it with cc -m32 is crashes.
* when compiling it with gcc -m
The following 2 references to GCC or gcc may not be intended
any more:
The
CCACHE_CPP2 option is used for Clang but not GCC.
To be able to build the system, either gcc
or clang bootstrap must be enabled unless an alternate compiler
is provided via XCC
wrote:
> > > > On 12/19/19 12:06 PM, Ryan Libby wrote:
> > > > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
> > > > >>
> > > > >> In the interest of supporting newer versions of GCC for a base system
> > > > >&
d, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
> > > >>
> > > >> In the interest of supporting newer versions of GCC for a base system
> > > >> toolchain, I've renamed the external GCC packages from -gcc
> > > >> to -gcc6. These are built
On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov wrote:
>
> On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote:
> > On 12/19/19 12:06 PM, Ryan Libby wrote:
> > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
> > >>
> > >> In the int
On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote:
> On 12/19/19 12:06 PM, Ryan Libby wrote:
> > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
> >>
> >> In the interest of supporting newer versions of GCC for a base system
> >> toolchain, I&
On 12/19/19 12:06 PM, Ryan Libby wrote:
> On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
>>
>> In the interest of supporting newer versions of GCC for a base system
>> toolchain, I've renamed the external GCC packages from -gcc
>> to -gcc6. These are built a
On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
>
> In the interest of supporting newer versions of GCC for a base system
> toolchain, I've renamed the external GCC packages from -gcc
> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6
> port. The xtool
On 12/18/19 4:16 PM, Mark Millard wrote:
>
>
> On 2019-Dec-18, at 13:48, John Baldwin wrote:
>
>> In the interest of supporting newer versions of GCC for a base system
>> toolchain, I've renamed the external GCC packages from -gcc
>> to -gcc6. These are buil
On 2019-Dec-18, at 13:48, John Baldwin wrote:
> In the interest of supporting newer versions of GCC for a base system
> toolchain, I've renamed the external GCC packages from -gcc
> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6
> port. The xtoolchain pa
In the interest of supporting newer versions of GCC for a base system
toolchain, I've renamed the external GCC packages from -gcc
to -gcc6. These are built as flavors of a new devel/freebsd-gcc6
port. The xtoolchain package is not used for these new packages, instead
one does 'pkg in
n that I can compile some simple things and everything
seems to work however I need to carefully specify where to find libgcc
and even libc as there are some oddball paths stuck in his bootstrap
result. Easy to work around. May even be enough to get a new bootstrap
going of gcc 9.2.0 but I have not b
:
>
> I will send this out to the only people and places that are likely to
> not simply be a black hole from which nothing ever returns. However
> most of my messages do just die on the mail lists with no reply from
> anyone ever and that is very true for the gcc maillists for anythin
be a black hole from which nothing ever returns. However
most of my messages do just die on the mail lists with no reply from
anyone ever and that is very true for the gcc maillists for anything
RISC-V related. I wish I knew why.
I am able to checkout and cross compile FreeBSD 13.0-CURRENT r354873
ts) = {};
21:21:52
^~~~
21:21:52
*** [bitstring_test.o] Error code 1
But, as of when I looked, none of the FreeBSD-head-amd64-gcc build attempts have
completed since then.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freeb
On 23 September 2018 at 07:31, Michael Tuexen wrote:
> Using this patch I was able to build/install world and kernel on an i386
> system.
> However, after removing it, I can't build world then. When trying to compile a
> kernel "the old way" I end up with:
>
> tuexen@head:~/head/sys/i386/conf % c
Resending from correct address...
> On 22. Sep 2018, at 05:57, Warner Losh wrote:
>
> Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
>
> They look good for me, but the only way you get this error is if they are
> wrong.
>
> Although from your typescript, I see:
>
> ===> l
On 9/21/18 10:10 PM, Rebecca Cran wrote:
> On 9/21/18 10:00 PM, Warner Losh wrote:
>
>> That may be the issue... Does the patch I included help? I'm building now
>> on my stable system, but it's slow...
>
> It does seem to have got further this time, so a cautious yes.
I can change that to a def
One thing that may allow progress is explicitly passing the path to a
new enough linker to make.
In the past when some I encountered a similar problem (I use
amd64-xtoolchain-gcc, amd64-gcc, and binutils for toolchain, and due
to some miscommunication the wrong linker was selected automatically
On 9/21/18 10:00 PM, Warner Losh wrote:
> That may be the issue... Does the patch I included help? I'm building now
> on my stable system, but it's slow...
It does seem to have got further this time, so a cautious yes.
--
Rebecca
___
freebsd-curren
On 9/21/18 9:57 PM, Warner Losh wrote:
> Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
>
> They look good for me, but the only way you get this error is if they
> are wrong.
bcran@cube:~/workspace/freebsd % make -V LINKER_TYPE
bfd
bcran@cube:~/workspace/freebsd % make -V
On Fri, Sep 21, 2018 at 9:59 PM Rebecca Cran wrote:
> On 9/21/18 9:57 PM, Warner Losh wrote:
>
> > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
> >
> > They look good for me, but the only way you get this error is if they
> > are wrong.
>
>
> bcran@cube:~/workspace/freebsd
Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
They look good for me, but the only way you get this error is if they are
wrong.
Although from your typescript, I see:
===> lib/libc (cleandir)
make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
amd64 libc
On Fri, Sep 21, 2018 at 9:34 PM Warner Losh wrote:
>
>
> On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote:
>
>> On 9/21/18 9:09 PM, Warner Losh wrote:
>>
>> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
>> > freebsd-toolch...@freebsd.org> wrote:
>> >
>> >> On 9/21/18 4
On 9/21/18 9:34 PM, Warner Losh wrote:
> What does ld.lld say?
>
> However, it shouldn't matter: we don't build libc until *AFTER* we
> build ld.lld, so this error is bogusly triggering. I suspect that it
> needs to be limited to only building targets, since tree traversal
> ones, as well as inst
On 9/21/18 9:35 PM, Warner Losh wrote:
>
> I meant to add, can you give a few lines before the error is spewed
> here in email? My IRC computer died before I could see any answers
> there...
>
> My 11.2-stable system has 6.0.1, so I can't test from there.
I've uploaded the full 'buildworld' outpu
On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote:
> On 9/21/18 9:09 PM, Warner Losh wrote:
>
> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
> > freebsd-toolch...@freebsd.org> wrote:
> >
> >> On 9/21/18 4:06 PM, Mark Johnston wrote:
> >>> https://reviews.freebsd.org/D17
On 9/21/18 9:09 PM, Warner Losh wrote:
> On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
> freebsd-toolch...@freebsd.org> wrote:
>
>> On 9/21/18 4:06 PM, Mark Johnston wrote:
>>> https://reviews.freebsd.org/D17279 for anyone else that would like to
>>> review.
>>
>> Is that po
On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
freebsd-toolch...@freebsd.org> wrote:
> On 9/21/18 4:06 PM, Mark Johnston wrote:
> >
> > https://reviews.freebsd.org/D17279 for anyone else that would like to
> > review.
>
>
> Is that possibly related to the error I'm getting tr
On 9/21/18 4:06 PM, Mark Johnston wrote:
>
> https://reviews.freebsd.org/D17279 for anyone else that would like to
> review.
Is that possibly related to the error I'm getting trying to build
-CURRENT on 11.2?
make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
amd64 libc req
On Fri, Sep 21, 2018 at 04:37:08PM -0400, Ed Maste wrote:
> On 21 September 2018 at 15:31, Mark Johnston wrote:
> >
> > Perhaps the following? It's not quite right since it'll still use
> > -zifunc-noplt with an external LLVM toolchain, but I can't seem to
> > figure out how to define a linker fe
On 21 September 2018 at 15:31, Mark Johnston wrote:
>
> Perhaps the following? It's not quite right since it'll still use
> -zifunc-noplt with an external LLVM toolchain, but I can't seem to
> figure out how to define a linker feature for only non-cross toolchains.
> In any case, we're going to u
On Fri, Sep 21, 2018 at 02:54:04PM -0400, Ed Maste wrote:
> On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain
> wrote:
> > In looking into another report about using devel/amd64-gcc to buld
> > head I tried a build of -r338675 ( with WERROR= ). It got:
> >
On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain
wrote:
> In looking into another report about using devel/amd64-gcc to buld
> head I tried a build of -r338675 ( with WERROR= ). It got:
>
...
>
> Question:
>
> Is ignoring "-z ifunc-noplt" a pr
In looking into another report about using devel/amd64-gcc to buld
head I tried a build of -r338675 ( with WERROR= ). It got:
--- kernel.full ---
linking kernel.full
/usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored.
ctfmerge -L VERSION -g -o kernel.full ...
text
Hi,
this works now but now I am back to this:
Updating ./version.texi
--- ./m4.info ---
restore=: && backupdir=".am$$" && am__cwd=`pwd` &&
CDPATH="${ZSH_VERSION+.}:" && cd . && rm -rf $backupdir && mkdir
$backupdir && if (/usr/bin/makeinfo --no-split --version) >/dev/null
2>&1; then for f
2>i
On Sat, Aug 04, 2018 at 10:23:56PM -0600, Brad Davis wrote:
> On Sat, Aug 4, 2018, at 9:48 PM, Brad Davis wrote:
> > On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote:
> > > > Author: brd
> > > > Date: Sat Aug 4 22:41:17 2018
> > > > New Revision: 337340
> > > > URL:
> > > > https://svnweb.free
On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote:
> > Author: brd
> > Date: Sat Aug 4 22:41:17 2018
> > New Revision: 337340
> > URL:
> > https://svnweb.freebsd.org/changeset/base/337340
> >
> >
> > Log:
> > Move autofs related configs to usr.sbin/autofs/
> >
> > This is prep for pkgb
On Sat, Aug 4, 2018, at 9:48 PM, Brad Davis wrote:
> On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote:
> > > Author: brd
> > > Date: Sat Aug 4 22:41:17 2018
> > > New Revision: 337340
> > > URL:
> > > https://svnweb.freebsd.org/changeset/base/337340
> > >
> > >
> > > Log:
> > > Move autofs
> Author: brd
> Date: Sat Aug 4 22:41:17 2018
> New Revision: 337340
> URL:
> https://svnweb.freebsd.org/changeset/base/337340
>
>
> Log:
> Move autofs related configs to usr.sbin/autofs/
>
> This is prep for pkgbase to have config files tagged as such.
>
> Approved by:will
I decided that it was better to fix our stdatomic.h, so I have a review
to do that at https://reviews.freebsd.org/D16585
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscri
RSION__ < 201112L */
>>
>>
>>
>>
>> The build with gcc's float.h also removed did complete instead of
>> stopping early.
>>
>>
>>
>> As for what x86_64-unknown-freebsd12.0 .h files were used:
>> (some may do include_nex
y.
>
>
>
> As for what x86_64-unknown-freebsd12.0 .h files were used:
> (some may do include_next back into FreeBSD headers)
>
>
> # find /usr/obj/amd64_xtoolchain-gcc/ -name "*.meta" -exec grep "^R
> .*/x86_64-unknown-freebsd12.0/.*\.h" {} \; |
{ T volatile __val; }
> #endif
> . . .
> #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */
Yes. It also means that if we didn't ship the compiler's stdatomic.h and
tried to build with -std=gnu11 or -std=c11 the compile would break.
Rather than requiring c11, another
k Millard wrote:
>>>>> . . .
>>>>
>>>> Yes, but the -E from above was when compiled with external GCC and it
>>>> didn't change
>>>> _Atomic(int). Here's part of the source of bar.c:
>>>>
>>>> #inclu
On 2018-Jul-26, at 9:06 PM, Mark Millard wrote:
> On 2018-Jul-26, at 6:14 PM, Mark Millard wrote:
>
>> On 2018-Jul-26, at 11:21 AM, John Baldwin wrote:
>>
>>> On 7/26/18 10:55 AM, Mark Millard wrote:
>>>> . . .
>>>
>>> Yes, but the
On 2018-Jul-26, at 6:14 PM, Mark Millard wrote:
> On 2018-Jul-26, at 11:21 AM, John Baldwin wrote:
>
>> On 7/26/18 10:55 AM, Mark Millard wrote:
>>> . . .
>>
>> Yes, but the -E from above was when compiled with external GCC and it didn't
>>
On 2018-Jul-26, at 11:21 AM, John Baldwin wrote:
> On 7/26/18 10:55 AM, Mark Millard wrote:
>> . . .
>
> Yes, but the -E from above was when compiled with external GCC and it didn't
> change
> _Atomic(int). Here's part of the source of bar.c:
>
>
On 7/16/18 11:27 PM, Mark Millard wrote:
> On 2018-Jul-1, at 6:34 AM, Mark Millard wrote:
>
>> My brain finally engaged for showing exactly what files are included
>> for the gcc builds: the .meta files include that information explicitly
>> (along with other files th
>> On 2018-Jul-25, at 10:09 AM, Mark Millard wrote:
>>>>
>>>>> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
>>>>>
>>>>>> On 7/24/18 11:39 PM, Mark Millard wrote:
>>>>>>> On 2018-Jul-24, at 10:32
gt; On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
>>>>
>>>>> On 7/24/18 11:39 PM, Mark Millard wrote:
>>>>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>>>>>
>>>>>>> https://ci.freebsd.org/job/FreeB
39 PM, Mark Millard wrote:
>>>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>>>>
>>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>>>>>> (head -r336573 after the prior 6596's
On 25/7/18 12:40 am, Julian Elischer wrote:
On 22/7/18 4:32 am, Dimitry Andric wrote:
On 21 Jul 2018, at 21:11, Yuri Pankov wrote:
Yuri Pankov wrote:
Julian Elischer wrote:
...
anyone know if there is a clang equivalent of -Wp, -E,-lang-asm?
In later GCC versions the cpp's -lang-asm
Mark Millard wrote:
>>>>
>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>>>>> (head -r336573 after the prior 6596's -r336565 ):
>>>>>
>>>>> --- all_subdir_lib/ofed ---
>>>>> In file inc
On 2018-Jul-25, at 10:09 AM, Mark Millard wrote:
> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
>
>> On 7/24/18 11:39 PM, Mark Millard wrote:
>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>>
>>>> https://ci.freebsd.org/job/FreeBSD-
On 7/25/18 10:09 AM, Mark Millard wrote:
>
>
> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
>
>> On 7/24/18 11:39 PM, Mark Millard wrote:
>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>>
>>>> https://ci.freebsd.org/job/FreeBSD-hea
On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
> On 7/24/18 11:39 PM, Mark Millard wrote:
>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>>> (head -r33657
On 7/24/18 11:39 PM, Mark Millard wrote:
> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>> (head -r336573 after the prior 6596's -r336565 ):
>>
>> --- all_subdir_lib/ofed ---
>
code in Samba from clang..
Julian
On 20/7/18 7:32 pm, Julian Elischer wrote:
compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour
when lld became the linker I think..
1/ linking needed some directories added to some of the build
scripts because previously apparently it looked in
On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
> (head -r336573 after the prior 6596's -r336565 ):
>
> --- all_subdir_lib/ofed ---
> In file included from /workspace/src/contrib/ofed/
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
(head -r336573 after the prior 6596's -r336565 ):
--- all_subdir_lib/ofed ---
In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0,
from /workspace/src/contrib/ofed/librdmacm/acm.c:42:
/work
On 22/7/18 4:32 am, Dimitry Andric wrote:
On 21 Jul 2018, at 21:11, Yuri Pankov wrote:
Yuri Pankov wrote:
Julian Elischer wrote:
...
anyone know if there is a clang equivalent of -Wp, -E,-lang-asm?
In later GCC versions the cpp's -lang-asm seems to be deprecated in
favor of -x asse
On 21 Jul 2018, at 21:11, Yuri Pankov wrote:
>
> Yuri Pankov wrote:
>> Julian Elischer wrote:
...
>>>> anyone know if there is a clang equivalent of -Wp, -E,-lang-asm?
>> In later GCC versions the cpp's -lang-asm seems to be deprecated in
>> favor of -x a
20/7/18 7:32 pm, Julian Elischer wrote:
compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour
when lld became the linker I think..
1/ linking needed some directories added to some of the build
scripts because previously apparently it looked in $SYSROOT/usr/lib
by default and now it
, Julian Elischer wrote:
compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour
when lld became the linker I think..
1/ linking needed some directories added to some of the build
scripts because previously apparently it looked in $SYSROOT/usr/lib
by default and now it doesn't.
2/ comp
:
compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour
when lld became the linker I think..
1/ linking needed some directories added to some of the build
scripts because previously apparently it looked in $SYSROOT/usr/lib
by default and now it doesn't.
2/ compiling our
compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour
when lld became the linker I think..
1/ linking needed some directories added to some of the build scripts
because previously apparently it looked in $SYSROOT/usr/lib by default
and now it doesn't.
2/ compiling our
On 2018-Jul-1, at 6:34 AM, Mark Millard wrote:
> My brain finally engaged for showing exactly what files are included
> for the gcc builds: the .meta files include that information explicitly
> (along with other files that are opened during the operation).
>
> amd64 is as I rep
Hi,
context: 12.0-CURRENT #0 r336037 amd64 / ports r474140
I get the following when installing aarch64-none-elf-gcc and related
programs from ports. It will build fine, just errors on install.
my /etc/make.conf looks like this:
> less /etc/make.conf
WRKDIRPREFIX=/buildports
MAKE_JOBS_NUM
My brain finally engaged for showing exactly what files are included
for the gcc builds: the .meta files include that information explicitly
(along with other files that are opened during the operation).
amd64 is as I reported, just one header file from gcc: float.h .
powerpc64 builds Lex
gt;>>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
>>>>
>>>>> On 6/29/18 2:37 PM, Mark Millard wrote:
>>>>>> [I expect this is more than just amd64-gcc related but that is all
>>>>>> that ci.freebsd.org normally builds vi
:
>>>>
>>>>> On 6/29/18 2:37 PM, Mark Millard wrote:
>>>>>> [I expect this is more than just amd64-gcc related but that is all
>>>>>> that ci.freebsd.org normally builds via a devel/*-gcc .]
>>>>>
>>>>&
t;>>>> [I expect this is more than just amd64-gcc related but that is all
>>>>> that ci.freebsd.org normally builds via a devel/*-gcc .]
>>>>
>>>> As indicated by my other mail, this is i386 and amd64 specific as it
>>>> only matter
On 2018-Jun-30, at 9:29 AM, John Baldwin wrote:
> On 6/30/18 9:17 AM, Mark Millard wrote:
>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
>>
>>> On 6/29/18 2:37 PM, Mark Millard wrote:
>>>> [I expect this is more than just amd64-gcc related but that is a
On 6/30/18 9:17 AM, Mark Millard wrote:
> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
>
>> On 6/29/18 2:37 PM, Mark Millard wrote:
>>> [I expect this is more than just amd64-gcc related but that is all
>>> that ci.freebsd.org normally builds via a devel/*-g
On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
> On 6/29/18 2:37 PM, Mark Millard wrote:
>> [I expect this is more than just amd64-gcc related but that is all
>> that ci.freebsd.org normally builds via a devel/*-gcc .]
>
> As indicated by my other mail, this is i386 and
On 6/29/18 2:37 PM, Mark Millard wrote:
> [I expect this is more than just amd64-gcc related but that is all
> that ci.freebsd.org normally builds via a devel/*-gcc .]
As indicated by my other mail, this is i386 and amd64 specific as it
only matters for float.h on i386 due to the disagreem
t;>>
>>>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
>>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
>>>> breaking-change was the following but I've not tried personal
>>>> builds to confirm.
>>
On 2018-Jun-29, at 2:37 PM, Mark Millard wrote:
> [I expect this is more than just amd64-gcc related but that is all
> that ci.freebsd.org normally builds via a devel/*-gcc .]
>
> On 2018-Jun-29, at 10:38 AM, John Baldwin wrote:
>
>> On 6/28/18 7:54 PM, Mark Millard wrot
(built) to -r335784 (failed)
>>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
>>>> breaking-change was the following but I've not tried personal
>>>> builds to confirm.
>>>> ]
>
> So this is a bit complicated and I&#
[I expect this is more than just amd64-gcc related but that is all
that ci.freebsd.org normally builds via a devel/*-gcc .]
On 2018-Jun-29, at 10:38 AM, John Baldwin wrote:
> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
>>
>>&
1 - 100 of 1713 matches
Mail list logo
