Re: port www/qt5-webengine fails reproducible at the same place compilation

El día jueves, septiembre 21, 2023 a las 05:03:15p. m. +0300, Gleb Popov escribió: > On Thu, Sep 21, 2023 at 4:47 PM Matthias Apitz wrote: > > > > Should I file a new PR? > > You should check git log: > https://cgit.freebsd.org/ports/commit/?id=190bd2d090115c5c38661198d16fd55288aeb9c1 > This

Re: port www/qt5-webengine fails reproducible at the same place compilation

On Thu, Sep 21, 2023 at 4:47 PM Matthias Apitz wrote: > > Should I file a new PR? You should check git log: https://cgit.freebsd.org/ports/commit/?id=190bd2d090115c5c38661198d16fd55288aeb9c1 This commit is just several commits later than the one you're building.

port www/qt5-webengine fails reproducible at the same place compilation

On a recent CURRENT (August 5) and ports from git September 13, the above port fails in poudriere reproducible at the same place during compilation: www/qt5-webengine for pkg qt5-webengine-5.15.8_6 failed after 02:46:52 with lines 120952 ff from poudriere log file qt5-webengine-5.15.8_6.log

Re: -CURRENT compilation time

On 09/09/2021 00:04, Tomoaki AOKI wrote: devel/ninja/Makefile has USES= python in it, so it maybe require python to run or at least build. You could probably remove that line without anyone noticing. Ninja uses Python for precisely one thing (or, at least, did last time I looked): There is

Re: -CURRENT compilation time

On Wed, Sep 8, 2021, 5:06 PM Tomoaki AOKI wrote: > On Wed, 8 Sep 2021 14:32:16 -0600 > Warner Losh wrote: > > > On Wed, Sep 8, 2021, 6:33 AM David Chisnall > wrote: > > > > > On 08/09/2021 11:52, Gary Jennejohn wrote: > > > > Seems to me that there was an earlier mail about getting CMAKE to >

Re: -CURRENT compilation time

On Wed, 8 Sep 2021 14:32:16 -0600 Warner Losh wrote: > On Wed, Sep 8, 2021, 6:33 AM David Chisnall wrote: > > > On 08/09/2021 11:52, Gary Jennejohn wrote: > > > Seems to me that there was an earlier mail about getting CMAKE to work > > > with FreeBSD builds. Could be worthwhile to look into

Re: -CURRENT compilation time

On Wed, Sep 8, 2021, 6:33 AM David Chisnall wrote: > On 08/09/2021 11:52, Gary Jennejohn wrote: > > Seems to me that there was an earlier mail about getting CMAKE to work > > with FreeBSD builds. Could be worthwhile to look into getting ninja > > to work also. But I could understand that there

Re: -CURRENT compilation time

k phase needs to wait for all object files. > > I really do not see that there is much to gain, here ... > > > In particular, building FreeBSD on a 10-24 core machine has very long > periods > > where a number of the cores are completely idle. > > I do not observe this, and

Re: -CURRENT compilation time

ATA drives in a RAIDZ1 configuration, which limits the I/O rate way below what an SSD based system might get.) > Ninja also has a few other nice features that improve performance relative to > bmake: > >  - It lets you put jobs in different pools.  In LLVM this is used to put link > and c

Re: -CURRENT compilation time

very long > periods where a number of the cores are completely idle. > > Ninja also has a few other nice features that improve performance > relative to bmake: > > - It lets you put jobs in different pools. In LLVM this is used to > put link and compile jobs in different p

Re: -CURRENT compilation time

On 08/09/2021 11:52, Gary Jennejohn wrote: Seems to me that there was an earlier mail about getting CMAKE to work with FreeBSD builds. Could be worthwhile to look into getting ninja to work also. But I could understand that there might be push-back, since the project prefers to use utilities

Re: -CURRENT compilation time

In particular, building FreeBSD on a 10-24 core machine has very > long periods where a number of the cores are completely idle. > > Ninja also has a few other nice features that improve performance > relative to bmake: > > - It lets you put jobs in different pools. In LLVM this

Re: -CURRENT compilation time

than compilation, so a 10-core machine may want to do 12 compile jobs in parallel but only 2 link jobs. This makes it much easier to completely saturate the machine. - Ninja provides each parallel build task with a separate pipe for stdout and stderr, and does not print their output unless

Re: -CURRENT compilation time

> From: David Chisnall > Date: Tue, 7 Sep 2021 14:51:21 +0100 > On 06/09/2021 20:34, Wolfram Schneider wrote: > > With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5 > > times faster (real or user+sys), down from 48 min to 19.5 min real > > time. > > Note that building LLVM with

Re: -CURRENT compilation time

Am 07.09.21 um 15:51 schrieb David Chisnall: > On 06/09/2021 20:34, Wolfram Schneider wrote: >> With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5 >> times faster (real or user+sys), down from 48 min to 19.5 min real >> time. > > Note that building LLVM with the upstream CMake +

Re: -CURRENT compilation time

On Tue, 7 Sep 2021, at 13:51, David Chisnall wrote: > One of the things I'd love to prototype if I had time is a CMake-based > build system for FreeBSD so that we could get all of the tooling > integration from the compile_commands.json, reuse LLVM's (and any other > contrib things that use

Re: -CURRENT compilation time

On 06/09/2021 20:34, Wolfram Schneider wrote: With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5 times faster (real or user+sys), down from 48 min to 19.5 min real time. Note that building LLVM with the upstream CMake + Ninja build system is *significantly* faster on a decent

Re: -CURRENT compilation time

Van: David Chisnall Datum: maandag, 6 september 2021 11:43 Aan: freebsd-current@freebsd.org Onderwerp: Re: -CURRENT compilation time On 06/09/2021 09:08, Jeremie Le Hen wrote: > Compiling C++ seems > extremely CPU heavy and this is made worse by the fact LLVM is built > twice (once

Re: -CURRENT compilation time

On Mon, 6 Sept 2021 at 11:44, David Chisnall wrote: > > On 06/09/2021 09:08, Jeremie Le Hen wrote: > > Compiling C++ seems > > extremely CPU heavy and this is made worse by the fact LLVM is built > > twice (once for build/cross tools, once for the actual world). > > Note that you need to build

Re: -CURRENT compilation time

On Mon, 6 Sept 2021 at 10:10, Jeremie Le Hen wrote: > > Hey, > > I want to build -CURRENT again from sources. It's been a long time > since I hadn't done that. I'm shocked by the compilation time. > > I started the whole thing on Friday night and Monday morning it's > stil

Re: -CURRENT compilation time

On Mon, 6 Sep 2021 10:43:06 +0100, David Chisnall wrote: > On 06/09/2021 09:08, Jeremie Le Hen wrote: > > Compiling C++ seems > > extremely CPU heavy and this is made worse by the fact LLVM is built > > twice (once for build/cross tools, once for the actual world). > > Note that you need to

Re: -CURRENT compilation time

On 06/09/2021 09:08, Jeremie Le Hen wrote: Compiling C++ seems extremely CPU heavy and this is made worse by the fact LLVM is built twice (once for build/cross tools, once for the actual world). Note that you need to build LLVM twice only if you are actively debugging LLVM reproduceable

Re: -CURRENT compilation time

On 06/09/21 10:08, Jeremie Le Hen wrote: Hey, I want to build -CURRENT again from sources. It's been a long time since I hadn't done that. I'm shocked by the compilation time. I started the whole thing on Friday night and Monday morning it's still in stage 4.2 (building libraries). Through

Re: -CURRENT compilation time

Jeremie, a few observations (from the POV of someone who builds current ~ once a month) On Mon, Sep 6, 2021 at 10:09 AM Jeremie Le Hen wrote: > Hey, > > I want to build -CURRENT again from sources. It's been a long time > since I hadn't done that. I'm shocked by the compilation

-CURRENT compilation time

Hey, I want to build -CURRENT again from sources. It's been a long time since I hadn't done that. I'm shocked by the compilation time. I started the whole thing on Friday night and Monday morning it's still in stage 4.2 (building libraries). Through occasional glancing at the screen over

RE: undefined symbol: random_source_register during kernel compilation

Good morning! I found a problem rather quickly: the compilation complains about a missing libcasper.h file. (/usr/include/capsicum_helpers.h references libcasper.h, and not from the sources but from the installed system. The problem is that casper is a feature which can be switched off

RE: undefined symbol: random_source_register during kernel compilation

INSTALL_NODEBUG=YES WITH_FAST_DEPEND=YES Compilation takes a few hours usually, I will tell you the result. best regards Andras Krasznai -Eredeti üzenet- Feladó: Pete Wright [mailto:p...@nomadlogic.org] Küldve: 2019. július 18. 19:10 Címzett: M - Krasznai András; freebsd-current

Re: undefined symbol: random_source_register during kernel compilation

ssing-meta=yes silent=yes verbose curdirOk= yes' I deleted and resynchronized the source tree and emptied the /usr/obj directory, but it did not help. How could I get kernel compilation work again? I would like to say that the make.conf, src.conf files as well as my kernel configur

undefined symbol: random_source_register during kernel compilation

KEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose curdirOk= yes' I deleted and resynchronized the source tree and emptied the /usr/obj directory, but it did not help. How could I get kernel compilation work again? I would like to say that the make.conf, src.

ZFS sends TIRMs to agressively? (Was: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system)

Hello Lev, Saturday, December 8, 2018, 7:58:37 PM, you wrote: >> Can you please narrow the problem down to a specific kernel revision? > I'm still not sure it is software or hardware problem. Looks like Samsung 850 EVO doesn't like TRIMs sent by ZFS (and I've thought it is good SSD,

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

Hello Mateusz, Saturday, December 8, 2018, 5:27:42 PM, you wrote: >> Looks like each next compiler invocation is slower and more stressful than >> previous one. > Is this a fresh install? Almost fresh. It was installed from some rather fresh 13 snapshot and then upgraded to r341157 and custom

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

On 12/8/18, Lev Serebryakov wrote: > Hello Lev, > > Saturday, December 8, 2018, 2:13:03 PM, you wrote: > > >> Even when build is single-job, system becomes unresponsive. With >> 4-job build running it could takes up to minute to switch screen's >> windows! > And even with 1-job kernel build

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

08.12.2018 18:13, Lev Serebryakov wrote: > I'm completely lost. Is it problem of software? Hardware? If it is > hardware problem what should I blame? Try using different kern.timecounter.hardware and/or kern.eventtimer.timer but first try kern.eventtimer.periodic=1 instead of default 0. If

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

Hello Eugene, Saturday, December 8, 2018, 4:27:13 PM, you wrote: >> I'm completely lost. Is it problem of software? Hardware? If it is >> hardware problem what should I blame? > Try using different kern.timecounter.hardware and/or kern.eventtimer.timer > but first try

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

Hello Lev, Saturday, December 8, 2018, 2:13:03 PM, you wrote: > Even when build is single-job, system becomes unresponsive. With > 4-job build running it could takes up to minute to switch screen's windows! And even with 1-job kernel build upsmon's connection to remote upsd flickers!

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

Hello Lev, Saturday, December 8, 2018, 2:13:03 PM, you wrote: > Another strange thing I noticed: when system is in such state, "top -SH" > shows that sometimes very low-profile processes, like clock software > interrupt (!) could consume large amount of CPU for short periods time. When >

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

‐‐‐ Original Message ‐‐‐ On Saturday, December 8, 2018 8:18 AM, Lev Serebryakov wrote: > Hello Lev, > > Saturday, December 8, 2018, 2:13:03 PM, you wrote: > > > Another strange thing I noticed: when system is in such state, "top -SH" > > shows that sometimes very low-profile processes,

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

Hello Lev, Saturday, December 8, 2018, 2:13:03 PM, you wrote: > I've checked all "standard" places — CPU is not throttling, SSD looks > perfectly Ok according to SMART and there is no complains from AHCI driver > about timeouts and such, system doesn't start to use swap. ZFS ARC was checked

Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

Hello Freebsd-hackers, I'm experiencing very strange situation on my lab system which is E3-1220v2, 8GiB of RAM and 850 EVO SATA SSD (with single ZFS pool). It runs CURRENT r341157. Kernel is built *without* INVARIANTS and other heavy debug aids. Everything works great — but compilation

Re: Compilation failure of the kernel for drm-next

Thanks for the help, all. Last night I set my computer to compile from the 12-CURRENT head and went to sleep. This morning, I installed the graphics/drm-next-kmod port and after a little troubleshooting (I had to set the compat.linuxkpi.enable_hangcheck=0 bootflag) I got it up and running.

Re: Compilation failure of the kernel for drm-next

On 2/27/2018 5:03 AM, Pete Wright wrote: On 02/26/2018 17:17, Mylan Connolly wrote: Hello all, I'm not sure if this is the best place to send this, but it looks like the issue tracker in Github is a bit dead. there may not be much traffic on it recently, but people are def still actively

Re: Compilation failure of the kernel for drm-next

On 02/26/2018 17:17, Mylan Connolly wrote: Hello all, I'm not sure if this is the best place to send this, but it looks like the issue tracker in Github is a bit dead. there may not be much traffic on it recently, but people are def still actively working on the repository and will see

Compilation failure of the kernel for drm-next

Hello all, I'm not sure if this is the best place to send this, but it looks like the issue tracker in Github is a bit dead. I have been trying to compile it for the past few weeks after downloading the latest code about once a week and it looks like this issue hasn't resolved itself. When I

SVN r323289 breaks i386 kernel compilation

On i386, this revision breaks compilation as follows: Building /usr/obj/usr/src/sys/SARAH/mca.o --- mca.o --- /usr/src/sys/x86/x86/mca.c:985:54: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat

Re: SVN r307866 compilation problem

On Mon, Oct 24, 2016 at 02:58:43PM -0400, Michael Butler wrote: > It seems that compilation of -current fails in the case that KDB is not > defined. > > I'm assuming that the following diff achieves what was intended: > > imb@vm01:/usr/src/sys/x86/x86> svn diff &

SVN r307866 compilation problem

It seems that compilation of -current fails in the case that KDB is not defined. I'm assuming that the following diff achieves what was intended: imb@vm01:/usr/src/sys/x86/x86> svn diff Index: cpu_machdep.c === --- cpu_machde

Re: SVN r303643 breaks non-SMP compilation

On 08/02/16 05:06, Mateusz Guzik wrote: > On Mon, Aug 01, 2016 at 09:49:03PM -0400, Michael Butler wrote: >> In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent >> reference to mtx_delay causes compilation of kern_mutex.c to fail >> because KDTRACE_HOOKS m

amd64-xtoolchain-gcc: small kernel compilation issue

/usr/src/sys/modules/vmm/../../amd64/vmm/vmm_dev.c: In function 'alloc_memseg': /usr/src/sys/modules/vmm/../../amd64/vmm/vmm_dev.c:261:3: error: null argument where non-null required (argument 1) [-Werror=nonnull] error = copystr(VM_MEMSEG_NAME(mseg), name, SPECNAMELEN + 1, 0); This is with

Re: SVN r303643 breaks non-SMP compilation

On Mon, Aug 01, 2016 at 09:49:03PM -0400, Michael Butler wrote: > In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent > reference to mtx_delay causes compilation of kern_mutex.c to fail > because KDTRACE_HOOKS may be, > Indeed, fixed in r303655. Thanks f

SVN r303643 breaks non-SMP compilation

In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent reference to mtx_delay causes compilation of kern_mutex.c to fail because KDTRACE_HOOKS may be, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

NGie Cooper wrote: > And here’s the real issue — .PATH is completely broken when > TARGET/TARGET_ARCH are specified as explicit values: It would help if you could indicate what you think the right value should be. > $ env MAKEOBJDIRPREFIX=/scratch/tmp/ngie/obj/ make

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: > > NGie Cooper wrote: >> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS >> and I ran into this linker issue below. I have no idea (yet) why it’s trying >> to compile an

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

> On Oct 30, 2015, at 23:51, NGie Cooper wrote: > > >> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >> >> NGie Cooper wrote: >>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS >>> and I ran into

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

> On Oct 31, 2015, at 14:37, NGie Cooper wrote: > > >> On Oct 30, 2015, at 23:51, NGie Cooper wrote: >> >> >>> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >>> >>> NGie Cooper wrote: I

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

On 10/30/2015 1:57 PM, NGie Cooper wrote: > Hi Bryan/Simon! > I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS > and I ran into this linker issue below. I have no idea (yet) why it’s trying > to compile an x64 object when I specify powerpc/powerpc — and more >

Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

Hi Bryan/Simon! I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no idea (yet) why it’s trying to compile an x64 object when I specify powerpc/powerpc — and more importantly, why is the object not being put in

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

On 10/30/2015 2:21 PM, Bryan Drewery wrote: > On 10/30/2015 1:57 PM, NGie Cooper wrote: >> Hi Bryan/Simon! >> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS >> and I ran into this linker issue below. I have no idea (yet) why it’s trying >> to compile an x64 object when

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote: > On 10/30/2015 3:03 PM, NGie Cooper wrote: > > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: > >> On 10/30/2015 2:21 PM, Bryan Drewery wrote: > >>> On 10/30/2015 1:57 PM, NGie Cooper wrote: > Hi

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

On 10/30/2015 4:08 PM, Mark Johnston wrote: > On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote: >> On 10/30/2015 3:03 PM, NGie Cooper wrote: >>> On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: On 10/30/2015 2:21 PM, Bryan Drewery wrote: > On

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

NGie Cooper wrote: > I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS > and I ran into this linker issue below. I have no idea (yet) why it’s trying > to compile an x64 object when I specify powerpc/powerpc — and more > importantly, why is the

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: > On 10/30/2015 2:21 PM, Bryan Drewery wrote: >> On 10/30/2015 1:57 PM, NGie Cooper wrote: >>> Hi Bryan/Simon! >>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS >>> and I ran into this linker

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

On 10/30/2015 3:03 PM, NGie Cooper wrote: > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: >> On 10/30/2015 2:21 PM, Bryan Drewery wrote: >>> On 10/30/2015 1:57 PM, NGie Cooper wrote: Hi Bryan/Simon! I tried doing buildworld on powerpc/powerpc with

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

On Fri, Oct 30, 2015 at 4:09 PM, Bryan Drewery wrote: ... > The example output must be a mistake as they are correct on ref11: > > ref11-amd64% find > /scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json > -name tst.usdt.o -exec file {} + >

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a,

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

Hi! > >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > This seems to create a run time dependency on GCC. Should it not just be > a build time dependency which allows you to uninstall GCC afterwards? Maybe, I have not looked into that. Can you suggest a patch ? --

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On Sep 25 09:18, Kurt Jaeger wrote: Hi! >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? Maybe, I have not looked into that. Can

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On 25 Sep, Matt Smith wrote: > On Sep 24 21:52, Kurt Jaeger wrote: >>Hi! >> >>> > > Try dropping the attached patch in net/mediatomb/files. I submitted it >>> > > in March, in PR198436: >>> > > >>> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 >>> > >>> > Eh, now with an actual

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On Sep 25 01:00, Don Lewis wrote: On 25 Sep, Matt Smith wrote: On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On 25 Sep, Matt Smith wrote: > On Sep 25 01:00, Don Lewis wrote: >>On 25 Sep, Matt Smith wrote: >>> On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > > Try dropping the attached patch in net/mediatomb/files. I > > > submitted it in March, in PR198436: > > > > > >

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

Hi! > > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > > in March, in PR198436: > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > > > Eh, now with an actual patch. :) > > Thanks, helps to build it. Still fails on 9.3a, but I *have* to go >

Port compilation fails on HEAD. works on 9 and 10 STABLE

met/mediatomb fails to compile with clang++36. Works fine with gcc++ and older versions of clang++. /usr/local/bin/clang++36 -DHAVE_CONFIG_H -I. -I.. -I../tombupnp/upnp/inc -I/usr/local/include -DLIBICONV_PLUG -I../src -I../tombupnp/ixml/inc -I../tombupnp/threadutil/inc -I../tombupnp/upnp/inc

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On 23 Sep 2015, at 21:57, Dimitry Andric wrote: > On 23 Sep 2015, at 17:38, Kevin Oberman wrote: >> >> met/mediatomb fails to compile with clang++36. Works fine with gcc++ and >> older versions of clang++. > > Try dropping the attached patch in

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On 23 Sep 2015, at 17:38, Kevin Oberman wrote: > > met/mediatomb fails to compile with clang++36. Works fine with gcc++ and > older versions of clang++. Try dropping the attached patch in net/mediatomb/files. I submitted it in March, in PR198436:

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a, but I *have* to go to bed now. --

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On Wed, Sep 23, 2015 at 1:39 PM, Kurt Jaeger wrote: > Hi! > > > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > > in March, in PR198436: > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > > > Eh, now with an actual patch. :) > >

Re: Need help reducing compilation warnings in CURRENT

On Thu, May 28, 2015 at 9:49 AM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, May 27, 2015 at 11:30:45PM -0700, Craig Rodrigues wrote: I take some time to do a pass over mine code or code I am somewhat knowledgable, to correct some 'assigned but not used variable' warnings. There

Re: Need help reducing compilation warnings in CURRENT

On May 30, 2015, at 19:15, Craig Rodrigues rodr...@freebsd.org wrote: On Thu, May 28, 2015 at 9:49 AM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, May 27, 2015 at 11:30:45PM -0700, Craig Rodrigues wrote: I take some time to do a pass over mine code or code I am somewhat

Re: Need help reducing compilation warnings in CURRENT

On Thu, May 28, 2015 at 12:18 PM, Baptiste Daroussin b...@freebsd.org wrote: ... If not upstreamed, there is a good chance it get lost during the next update. So in the special case of warning fixes, I would strongly advice to upstream first!! +200 Plus upstream sources generally get

Re: Need help reducing compilation warnings in CURRENT

On 28 May 2015, at 21:09, Craig Rodrigues rodr...@freebsd.org wrote: On Thu, May 28, 2015 at 5:38 AM, Johannes Jost Meixner x...@freebsd.org ... The warnings are almost all in contrib/ areas. Hence, any fix might want to probably be submitted to upstream first. Sure, if we can push fixes

Re: Need help reducing compilation warnings in CURRENT

On Thu, May 28, 2015 at 5:38 AM, Johannes Jost Meixner x...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Craig, I'll gladly help (good excuse to learn C), but looking at those errors in general, one thing pops out: The warnings are almost all in contrib/ areas.

Re: Need help reducing compilation warnings in CURRENT

On Thu, May 28, 2015 at 12:09:35PM -0700, Craig Rodrigues wrote: On Thu, May 28, 2015 at 5:38 AM, Johannes Jost Meixner x...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Craig, I'll gladly help (good excuse to learn C), but looking at those errors in

Re: Need help reducing compilation warnings in CURRENT

On Thu, May 28, 2015 at 5:45 AM, Muhammad Moinur Rahman b...@freebsd.org wrote: Hi, Can anyone give me any ideas about how can I contribute some of my idle times? Do I need commit bit to submit patches in Jenkins? Or should I submit through CODE Review? Please read this:

Need help reducing compilation warnings in CURRENT

Hi, I've configured Jenkins to highlight compiler warnings and generate a table. Jenkins also keeps track of new compiler warnings over time. See: https://jenkins.freebsd.org/job/FreeBSD_HEAD/warnings7 Can anyone help improve the code by periodically looking at this table and submitting

Re: Need help reducing compilation warnings in CURRENT

Hi Craig, I can give a hand with it. Best, 2015-05-28 14:30 GMT+08:00 Craig Rodrigues rodr...@freebsd.org: Hi, I've configured Jenkins to highlight compiler warnings and generate a table. Jenkins also keeps track of new compiler warnings over time. See:

Re: Need help reducing compilation warnings in CURRENT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Craig, I'll gladly help (good excuse to learn C), but looking at those errors in general, one thing pops out: The warnings are almost all in contrib/ areas. Hence, any fix might want to probably be submitted to upstream first. Correct me if

Re: Need help reducing compilation warnings in CURRENT

Hi, Can anyone give me any ideas about how can I contribute some of my idle times? Do I need commit bit to submit patches in Jenkins? Or should I submit through CODE Review? BR, @bofh On Thu, May 28, 2015 at 6:38 PM, Johannes Jost Meixner x...@freebsd.org wrote: -BEGIN PGP SIGNED

Re: Need help reducing compilation warnings in CURRENT

Hi, You don't need src bit to submit any patch and you can do it via review without any problem. Just try to drive the patch to the right person. Best, 2015-05-28 20:45 GMT+08:00 Muhammad Moinur Rahman b...@freebsd.org: Hi, Can anyone give me any ideas about how can I contribute some of my

Re: Need help reducing compilation warnings in CURRENT

On Wed, May 27, 2015 at 11:30:45PM -0700, Craig Rodrigues wrote: Hi, I've configured Jenkins to highlight compiler warnings and generate a table. Jenkins also keeps track of new compiler warnings over time. See: https://jenkins.freebsd.org/job/FreeBSD_HEAD/warnings7 Can anyone help

Re: [Request for Help] Reducing gcc 4.9 compilation warnings

On Sun, Apr 19, 2015 at 2:10 AM, Eitan Adler li...@eitanadler.com wrote: Perhaps it would be useful to do a second run of this, but with a modified share/mk to silence the most useless of these warnings? Sure, that's fine. Can you provide a modified share/mk which you think does the right

Re: [Request for Help] Reducing gcc 4.9 compilation warnings

On Sun, 19 Apr 2015, Adrian Chadd wrote: I just got a booting mips32 kernel using gcc-4.9.2, and boy are there a lot of warnings. I'm going to start fixing the ones I find - cleaner code is better code. Mostly. (I'd be happy with -Wall -Werror.) I thought that -Wall was a fixed set of

Re: [Request for Help] Reducing gcc 4.9 compilation warnings

://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001658.html The boot2 compilation errors still need to be worked on. However, most other things compile with warnings. If folks are interested in looking at the warnings, you can see them here: https://jenkins.freebsd.org/job

Re: [Request for Help] Reducing gcc 4.9 compilation warnings

to skip boot2 from building because of errors reported here: https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001658.html The boot2 compilation errors still need to be worked on. However, most other things compile with warnings. If folks are interested in looking

[Request for Help] Reducing gcc 4.9 compilation warnings

compilation errors still need to be worked on. However, most other things compile with warnings. If folks are interested in looking at the warnings, you can see them here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/warnings17 Please look at these warnings, and if you see places

emulators/virtualbox-ose: compilation on CURRENT fails due to: tstVMStructRC: 1: Syntax error: ( unexpected

compilation of port emulators/virtualbox-ose, although I already updated the ports tree and did successfully a portmaster -R -fd /emulators/virtualbox-ose. Since I use some non-standard optimization flags in /etc/src.conf and /etc/make.conf (-O3 and CPUTYPE=native instead of plain -O and outdated

SVN r273734 breaks i386 compilation

The updates to dd cause this on an i386 .. === bin/dd (all) cc -O2 -pipe -march=pentium4 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings

Re: SVN r273734 breaks i386 compilation

Hi! The updates to dd cause this on an i386 .. Yes, I'm sorry. Change reverted. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-current@freebsd.org mailing list

i386 compilation errors in head/sys/dev/ixl/if_ixl.c

Compilation errors occur in head/sys/dev/ixl/if_ixl.c on i386 for FreeBSD 11-current for the following: In function ixl_print_debug_info() printf(Queue irqs = %lx\n, que-irqs); printf(AdminQ irqs = %lx\n, pf-admin_irq); ... printf(RX not ready = %lx\n, rxr-not_done

Re: i386 compilation errors in head/sys/dev/ixl/if_ixl.c

Looks like this was already fixed by: http://svnweb.freebsd.org/changeset/base/270799 Regards Steve - Original Message - From: David Shao davs...@gmail.com To: freebsd-current@freebsd.org Sent: Friday, August 29, 2014 6:38 AM Subject: i386 compilation errors in head/sys/dev/ixl

Re: i386 compilation errors in head/sys/dev/ixl/if_ixl.c

On 29 Aug 2014, at 12:02 , Steven Hartland kill...@multiplay.co.uk wrote: Looks like this was already fixed by: http://svnweb.freebsd.org/changeset/base/270799 Yes, just before I closed the bugreport. There’s a few more follow-up commits that (if I didn’t screw up) should make things at

Re: i386 compilation errors in head/sys/dev/ixl/if_ixl.c

On Fri, Aug 29, 2014 at 12:55:40PM +, Bjoern A. Zeeb wrote: On 29 Aug 2014, at 12:02 , Steven Hartland kill...@multiplay.co.uk wrote: Looks like this was already fixed by: http://svnweb.freebsd.org/changeset/base/270799 Yes, just before I closed the bugreport. There?s a few more

  1   2   3   >