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

[Matthias Apitz]

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 commit is just several commits later than the one you're building.
> 

I checked the git log, but in direction of the past because on August
nn, it still compiled, with

cd www/qt5-webengine
git log .

to see if one of the recent changes could cause it.

OK, lesson learned. Thanks


matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

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

[Gleb Popov]

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

[Matthias Apitz]

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 
 
120952 
../../../../qtwebengine-everywhere-src-5.15.8/src/3rdparty/chromium/gpu/command_buffer/service/program_manager.cc:627:25:
 error: no member named 'as_string' in 'absl::string_view'
120953   return output + input.as_string();
120954   ~ ^
120955 7 warnings and 1 error generated.
... (~500 lines deleted)
121476 9 warnings generated.
121477 ninja: build stopped: subcommand failed.
121478 *** [run_ninja] Error code 1

there is a similar package fallout as mail in 
https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg2193618.html
to k...@freebsd.org

The full log is here: http://www.unixarea.de/qt5-webengine-5.15.8_6.log.txt

Should I file a new PR?

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: -CURRENT compilation time

[David Chisnall]

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 a debugging mode that will generate a visualisation of all of 
the dependencies in the project and run a web server that allows you to 
view this visualisation in your web browser.


In about 10 years of using Ninja, I have used this functionality 
precisely once, and that was immediately after poking the code to find 
out why it had a Python dependency, discovering this mode existed, and 
looking to see what it did.


Nothing on the build paths depends on Python and Ninja doesn't require 
Python to build itself.


David

Re: -CURRENT compilation time

[Warner Losh]

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
> 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 from the source tree.
> > >
> > > CMake is a build-system generator, Ninja is a build system.  Usually
> the
> > > two are used together: CMake generates Ninja files, Ninja runs the
> > > build.  Ninja is explicitly designed not to be written by hand.
> > >
> > > CMake can also emit other things, including POSIX Makefiles, but the
> > > Ninja build is usually the fastest.
> > >
> > > CMake and Ninja are both in package systems for Windows, macOS, *BSD,
> > > and all Linux distros that I've seen, unlike bmake, so  universally
> easy
> > > to depend on for cross-builds.  Cross compiling with bmake is much
> > > harder harder from anything that isn't FreeBSD.
> > >
> >
> > This may be true. I've never had a problem on mac or linux, but my
> windows
> > experience is thin.
> >
> > I got looking at the problem, btw, to see if ninja was faster than meta
> > mode. Ninja files aren't horrible to generate, but I never got past the
> > early proof of concept phase... it seemed possible to implement a make
> > ninja target... I'd wanted to use this day to day if it was better than
> > meta.
> >
> > Mason, however looked much harder to generate, but I didn't spend a lot
> of
> > time on it. I would think this sort of work would be more of a one shot.
> > Didn't look at cmake at all, but I imagine it would be similar...
> >
> > Warner
> >
> > >
>
> What about devel/samurai, ninja-compatible build tool written in C?
>
> devel/ninja/Makefile has USES= python in it, so it maybe require python
> to run or at least build.
>
> In addition, ports framework can use it instead of ninja.
> See {PORTSDIR}/Mk/Uses/ninja.mk.
>

I'll have to take a look next time I play with this stuff

Warner

-- 
> Tomoaki AOKI
>
>

Re: -CURRENT compilation time

[Tomoaki AOKI]

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 getting ninja
> > > to work also.  But I could understand that there might be push-back,
> > > since the project prefers to use utilities from the source tree.
> >
> > CMake is a build-system generator, Ninja is a build system.  Usually the
> > two are used together: CMake generates Ninja files, Ninja runs the
> > build.  Ninja is explicitly designed not to be written by hand.
> >
> > CMake can also emit other things, including POSIX Makefiles, but the
> > Ninja build is usually the fastest.
> >
> > CMake and Ninja are both in package systems for Windows, macOS, *BSD,
> > and all Linux distros that I've seen, unlike bmake, so  universally easy
> > to depend on for cross-builds.  Cross compiling with bmake is much
> > harder harder from anything that isn't FreeBSD.
> >
> 
> This may be true. I've never had a problem on mac or linux, but my windows
> experience is thin.
> 
> I got looking at the problem, btw, to see if ninja was faster than meta
> mode. Ninja files aren't horrible to generate, but I never got past the
> early proof of concept phase... it seemed possible to implement a make
> ninja target... I'd wanted to use this day to day if it was better than
> meta.
> 
> Mason, however looked much harder to generate, but I didn't spend a lot of
> time on it. I would think this sort of work would be more of a one shot.
> Didn't look at cmake at all, but I imagine it would be similar...
> 
> Warner
> 
> >

What about devel/samurai, ninja-compatible build tool written in C?

devel/ninja/Makefile has USES= python in it, so it maybe require python
to run or at least build.

In addition, ports framework can use it instead of ninja.
See {PORTSDIR}/Mk/Uses/ninja.mk.


-- 
Tomoaki AOKI

Re: -CURRENT compilation time

[Warner Losh]

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 might be push-back,
> > since the project prefers to use utilities from the source tree.
>
> CMake is a build-system generator, Ninja is a build system.  Usually the
> two are used together: CMake generates Ninja files, Ninja runs the
> build.  Ninja is explicitly designed not to be written by hand.
>
> CMake can also emit other things, including POSIX Makefiles, but the
> Ninja build is usually the fastest.
>
> CMake and Ninja are both in package systems for Windows, macOS, *BSD,
> and all Linux distros that I've seen, unlike bmake, so  universally easy
> to depend on for cross-builds.  Cross compiling with bmake is much
> harder harder from anything that isn't FreeBSD.
>

This may be true. I've never had a problem on mac or linux, but my windows
experience is thin.

I got looking at the problem, btw, to see if ninja was faster than meta
mode. Ninja files aren't horrible to generate, but I never got past the
early proof of concept phase... it seemed possible to implement a make
ninja target... I'd wanted to use this day to day if it was better than
meta.

Mason, however looked much harder to generate, but I didn't spend a lot of
time on it. I would think this sort of work would be more of a one shot.
Didn't look at cmake at all, but I imagine it would be similar...

Warner

>

Re: -CURRENT compilation time

[Warner Losh]

>> World built in 652 seconds, ncpu: 32, make -j32
> --
>   652.14 real 17857.03 user   753.41 sys
>
> Calculating "(user + sys) / real" I get factors between 10 (in case
> of only minor changes) to 28 for larger recompiles (e.g. if lots
> of source files depend on an updated header), with 32 the theoretical
> limit for all cores continuously active during the build.
>
> META_MODE does not understand that updated build tools do not always
> require a full rebuild, but special cases have been added to the
> Makefile to reduce the number of unnecessary rebuilds.
>
> > Working on LLVM, I generally spend well under 10% of my time either
> waiting for
> > builds or fighting the build system.  Working on FreeBSD, I generally
> spend
> > over 90% of my time waiting for builds or fighting the build system.
> This
> > means that my productivity contributing to FreeBSD is almost zero.
> >
> > For reference, changes to LLVM typically build for me in under 30
> seconds with
> > Ninja, unless I've changed a header that everything
>
> You should get the same effect from META_MODE.
>
> And META_MODE allows to execute make in any subtree of a larger source
> tree, provided there is a Makefile for that part of the sources, e.g.:
>
> $ cd /usr/src/usr.bin/clang/lld
> $ make -j 32
> [...]
> $ touch /usr/src/contrib/llvm-project/lld/Common/Strings.cpp
> $ time make -j 32
> Building
> /usr/obj/usr/git/src/amd64.amd64/usr.bin/clang/lld/Common/Strings.o
> Building /usr/obj/usr/git/src/amd64.amd64/usr.bin/clang/lld/ld.lld.full
> Building /usr/obj/usr/git/src/amd64.amd64/usr.bin/clang/lld/ld.lld.debug
> Building /usr/obj/usr/git/src/amd64.amd64/usr.bin/clang/lld/ld.lld
>
> real0m1.699s
> user0m1.454s
> sys 0m3.745s
>
> This assumes that your world is up-to-date in general, which should be
> the case when working on a single component, e.g. one of the programs
> belonging to CLANG/LLVM. Compiling a single file and linking a single
> target does of course not allow for any parallelism.
>
> $ cd /usr/src/usr.bin/clang
> $ time make -j 32 > /dev/null
> real0m24.650s
> user8m58.381s
> sys 0m34.786s
>
> Some files have changed between the last "make buildworld" and now, but
> it takes less than 10 minutes of CPU time (i.e. 1 minute real time on
> a system with 6 cores / 12 threads) to update the obj directory. My
> system got an overall parallelism of 24 on that run ...
>
> And thereafter, there is hardly any overhead caused by bmake:
>
> $ time make -j 32 > /dev/null
> real0m0.064s
> user0m0.453s
> sys 0m0.029s
>
> The overhead for scanning all LLVM components if there was no change is
> absolutely negligible.
>
> Now lets touch a header that is included in a number of files:
>
> $ touch /usr/src/contrib/llvm-project/lld/include/lld/Common/Strings.h
> $ time make -j 32 | wc
>   41  823130
>
> real0m17.727s
> user2m56.021s
> sys 0m8.237s
>
> The ratio of user+sys to real is a little above 10, which is not too bad
> if you consider that the link 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 I'm using a 16 core / 32 thread CPU, which
> would be busy on all cores with just 16 parallel threads, just not
> taking advantage of SMT. And I see an overall factor (and load average)
> of 10 for small changes (with lots of I/O and little processing),
> 28 and beyond if larger parts of the system need to be rebuild.
> (BTW: This is a system with SATA 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 compile jobs in different pools because linking with LLD uses
> multiple
> > threads and a lot more memory 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.
>
> That may be an advantage on systems with relatively small RAM (compared to
> the number of threads supported in parallel).
>
> But I do see compilations and linking executing in parallel, i.e. just one
> linker activation while compiles run in p

Re: -CURRENT compilation time

[Stefan Esser]

ebuild, but special cases have been added to the
Makefile to reduce the number of unnecessary rebuilds.

> Working on LLVM, I generally spend well under 10% of my time either waiting 
> for
> builds or fighting the build system.  Working on FreeBSD, I generally spend
> over 90% of my time waiting for builds or fighting the build system.  This
> means that my productivity contributing to FreeBSD is almost zero.
> 
> For reference, changes to LLVM typically build for me in under 30 seconds with
> Ninja, unless I've changed a header that everything

You should get the same effect from META_MODE.

And META_MODE allows to execute make in any subtree of a larger source
tree, provided there is a Makefile for that part of the sources, e.g.:

$ cd /usr/src/usr.bin/clang/lld
$ make -j 32
[...]
$ touch /usr/src/contrib/llvm-project/lld/Common/Strings.cpp
$ time make -j 32
Building /usr/obj/usr/git/src/amd64.amd64/usr.bin/clang/lld/Common/Strings.o
Building /usr/obj/usr/git/src/amd64.amd64/usr.bin/clang/lld/ld.lld.full
Building /usr/obj/usr/git/src/amd64.amd64/usr.bin/clang/lld/ld.lld.debug
Building /usr/obj/usr/git/src/amd64.amd64/usr.bin/clang/lld/ld.lld

real0m1.699s
user0m1.454s
sys 0m3.745s

This assumes that your world is up-to-date in general, which should be
the case when working on a single component, e.g. one of the programs
belonging to CLANG/LLVM. Compiling a single file and linking a single
target does of course not allow for any parallelism.

$ cd /usr/src/usr.bin/clang
$ time make -j 32 > /dev/null
real0m24.650s
user8m58.381s
sys 0m34.786s

Some files have changed between the last "make buildworld" and now, but
it takes less than 10 minutes of CPU time (i.e. 1 minute real time on
a system with 6 cores / 12 threads) to update the obj directory. My
system got an overall parallelism of 24 on that run ...

And thereafter, there is hardly any overhead caused by bmake:

$ time make -j 32 > /dev/null
real0m0.064s
user0m0.453s
sys 0m0.029s

The overhead for scanning all LLVM components if there was no change is
absolutely negligible.

Now lets touch a header that is included in a number of files:

$ touch /usr/src/contrib/llvm-project/lld/include/lld/Common/Strings.h
$ time make -j 32 | wc
  41  823130

real0m17.727s
user2m56.021s
sys 0m8.237s

The ratio of user+sys to real is a little above 10, which is not too bad
if you consider that the link 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 I'm using a 16 core / 32 thread CPU, which
would be busy on all cores with just 16 parallel threads, just not
taking advantage of SMT. And I see an overall factor (and load average)
of 10 for small changes (with lots of I/O and little processing),
28 and beyond if larger parts of the system need to be rebuild.
(BTW: This is a system with SATA 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 compile jobs in different pools because linking with LLD uses multiple
> threads and a lot more memory 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.

That may be an advantage on systems with relatively small RAM (compared to
the number of threads supported in parallel).

But I do see compilations and linking executing in parallel, i.e. just one
linker activation while compiles run in parallel. Due to the multi-threaded
execution of LLD that might cause the load average to slightly exceed the
number of threads, but only for a relatively short period of time.

>  - Ninja provides each parallel build task with a separate pipe for stdout and
> stderr, and does not print their output unless a build step fails (or unless
> you build with -v).  With bmake, if a parallel build fails I have to rerun the
> build without -j, because the output is interleaved with succeeding jobs and
> it's difficult to see what actually failed.  With ninja, the output is from
> each failed job, with no interleaving.

This makes it easier to spot the error line, but I've got used to the way
the output is formatted by a parallel make run.

I always redirect the output into a file (either with nohup or with tee,
depending on whether I plan to watch the build). I hardly ever have to use
a single threaded build to spot an error, it is generally obvious from the
build log in that file.

But I do agree that separate output per build job makes this easier, just
not enough that I'd want to rework the whole build system. And especially
not if it breaks META_MODE.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: -CURRENT compilation time

[Warner Losh]

On Wed, Sep 8, 2021 at 2:59 AM David Chisnall  wrote:

> On 07/09/2021 18:02, Stefan Esser wrote:
> > Wouldn't this break META_MODE?
>
> I have never managed to get META_MODE to work but my understanding is
> that META_MODE is addressing a problem that doesn't really exist in any
> other build system that I've used: that dependencies are not properly
> tracked.
>

It does track the dependencies. It uses filemon(4) to do this so that
every dependency is tracked. This is better than what other build systems
do because no dependencies are missed.


> When I do a build of LLVM with the upstream build system with no
> changes, it takes Ninja approximately a tenth of a second to stat all of
> the relevant files and tell me that I have no work to do.  META_MODE
> apparently lets the FreeBSD build system extract these dependencies and
> do something similar, but it's not enabled by default and it's difficult
> to make work.
>

META_MODE does the same thing, and it's just as fast as ninja make. And
it has the advantage that, unlike meson, it isn't rebuilding the makefiles
all
the time. And apart from loading filmon, it was quite easy to enable last
time
I was using it (though I did have trouble finding the right docs).


> > I'd rather be able to continue building the world within a few minutes
> > (generally much less than 10 minutes, as long as there is no major LLVM
> > upgrade) than have a faster LLVM build and then a slower build of the
> world ...
>
> The rest of this thread has determined that building LLVM accounts for
> half of the build time in a clean FreeBSD build.  LLVM's CMake is not a
> great example: it has been incrementally improved since CMake 2.8 and
> doesn't yet use any of the modern CMake features that allow
> encapsulating targets and providing import / export configurations.
>
> In spite of that, it generates a ninja file that compiles
> *significantly* faster than the bmake-based system in FreeBSD.  In other
> projects that I've worked on with a similar-sized codebase to FreeBSD
> that use CMake + Ninja, I've never had the same problems with build
> speed that I have with FreeBSD.
>

The speed is comparable to META_MODE, but much faster than the
default. It suffers a bit because our buildworld stuff is a kinda sorts not
quite good enough dependency tracker and it's layered on top of that.


> Working on LLVM, I generally spend well under 10% of my time either
> waiting for builds or fighting the build system.  Working on FreeBSD, I
> generally spend over 90% of my time waiting for builds or fighting the
> build system.  This means that my productivity contributing to FreeBSD
> is almost zero.
>
> For reference, changes to LLVM typically build for me in under 30
> seconds with Ninja, unless I've changed a header that everything
>
> 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 is used to
> put link and compile jobs in different pools because linking with LLD
> uses multiple threads and a lot more memory 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.
>

This is nice.


>   - Ninja provides each parallel build task with a separate pipe for
> stdout and stderr, and does not print their output unless a build step
> fails (or unless you build with -v).  With bmake, if a parallel build
> fails I have to rerun the build without -j, because the output is
> interleaved with succeeding jobs and it's difficult to see what actually
> failed.  With ninja, the output is from each failed job, with no
> interleaving.
>

META_MODE does this too. It's the primary reason I use it, along with
the speed.

The big downside of ninja make is that  it requires you to have some
other, higher-level build system to generate the Makefiles. And my
experience to date with meson is a mixed bag: it's quite a bit better
than normal bmake for some things, and quite a bit worse for others
in terms of the code you need to write to get things done, or the
efforts required to debug mistakes. I've not used cmake as the ninja
makefile generator, so I have no comments on it.

Doing the conversion to at least meson would be a quite large
job, at least by my initial estimates. Hacking bmake to generate
ninja makefiles looks to be quite a bit simpler...  But looks can
be deceiving.

Warner

Re: -CURRENT compilation time

[David Chisnall]

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 from the source tree.


CMake is a build-system generator, Ninja is a build system.  Usually the 
two are used together: CMake generates Ninja files, Ninja runs the 
build.  Ninja is explicitly designed not to be written by hand.


CMake can also emit other things, including POSIX Makefiles, but the 
Ninja build is usually the fastest.


CMake and Ninja are both in package systems for Windows, macOS, *BSD, 
and all Linux distros that I've seen, unlike bmake, so  universally easy 
to depend on for cross-builds.  Cross compiling with bmake is much 
harder harder from anything that isn't FreeBSD.


David

Re: -CURRENT compilation time

[Gary Jennejohn]

On Wed, 8 Sep 2021 09:57:50 +0100
David Chisnall  wrote:

> On 07/09/2021 18:02, Stefan Esser wrote:
> > Wouldn't this break META_MODE?  
> 
> I have never managed to get META_MODE to work but my understanding
> is that META_MODE is addressing a problem that doesn't really exist
> in any other build system that I've used:  that dependencies are not
> properly tracked.
> 

META_MODE requires filemon(4) to be in the kernel or loaded as a module.
make(1) will use if it's available with .MAKE.MODE=meta.

> When I do a build of LLVM with the upstream build system with no
> changes, it takes Ninja approximately a tenth of a second to stat
> all of the relevant files and tell me that I have no work to do. 
> META_MODE apparently lets the FreeBSD build system extract these
> dependencies and do something similar, but it's not enabled by
> default and it's difficult to make work.
> 
> > I'd rather be able to continue building the world within a few
> > minutes (generally much less than 10 minutes, as long as there is
> > no major LLVM upgrade) than have a faster LLVM build and then a
> > slower build of the world ... 
> 
> The rest of this thread has determined that building LLVM accounts
> for half of the build time in a clean FreeBSD build.  LLVM's CMake
> is not a great example:  it has been incrementally improved since
> CMake 2.8 and doesn't yet use any of the modern CMake features that
> allow encapsulating targets and providing import / export
> configurations.
> 
> In spite of that, it generates a ninja file that compiles
> *significantly* faster than the bmake-based system in FreeBSD.  In
> other projects that I've worked on with a similar-sized codebase to
> FreeBSD that use CMake + Ninja, I've never had the same problems
> with build speed that I have with FreeBSD.
> 
> Working on LLVM, I generally spend well under 10% of my time either
> waiting for builds or fighting the build system.  Working on
> FreeBSD, I generally spend over 90% of my time waiting for builds or
> fighting the build system.  This means that my productivity
> contributing to FreeBSD is almost zero.
> 
> For reference, changes to LLVM typically build for me in under 30
> seconds with Ninja, unless I've changed a header that everything
> 
> 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 is used to
> put link and compile jobs in different pools because linking with
> LLD uses multiple threads and a lot more memory 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 a build
> step fails (or unless you build with -v).  With bmake, if a parallel
> build fails I have to rerun the build without -j, because the output
> is interleaved with succeeding jobs and it's difficult to see what
> actually failed.  With ninja, the output is from each failed job,
> with no interleaving.
> 

ninja sounds really neat and it's available as /usr/ports/devel/ninja.

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 from the source tree.

-- 
Gary Jennejohn

Re: -CURRENT compilation time

[David Chisnall]

On 07/09/2021 18:02, Stefan Esser wrote:

Wouldn't this break META_MODE?


I have never managed to get META_MODE to work but my understanding is 
that META_MODE is addressing a problem that doesn't really exist in any 
other build system that I've used: that dependencies are not properly 
tracked.


When I do a build of LLVM with the upstream build system with no 
changes, it takes Ninja approximately a tenth of a second to stat all of 
the relevant files and tell me that I have no work to do.  META_MODE 
apparently lets the FreeBSD build system extract these dependencies and 
do something similar, but it's not enabled by default and it's difficult 
to make work.



I'd rather be able to continue building the world within a few minutes
(generally much less than 10 minutes, as long as there is no major LLVM
upgrade) than have a faster LLVM build and then a slower build of the world ...


The rest of this thread has determined that building LLVM accounts for 
half of the build time in a clean FreeBSD build.  LLVM's CMake is not a 
great example: it has been incrementally improved since CMake 2.8 and 
doesn't yet use any of the modern CMake features that allow 
encapsulating targets and providing import / export configurations.


In spite of that, it generates a ninja file that compiles 
*significantly* faster than the bmake-based system in FreeBSD.  In other 
projects that I've worked on with a similar-sized codebase to FreeBSD 
that use CMake + Ninja, I've never had the same problems with build 
speed that I have with FreeBSD.


Working on LLVM, I generally spend well under 10% of my time either 
waiting for builds or fighting the build system.  Working on FreeBSD, I 
generally spend over 90% of my time waiting for builds or fighting the 
build system.  This means that my productivity contributing to FreeBSD 
is almost zero.


For reference, changes to LLVM typically build for me in under 30 
seconds with Ninja, unless I've changed a header that everything


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 is used to 
put link and compile jobs in different pools because linking with LLD 
uses multiple threads and a lot more memory 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 a build step 
fails (or unless you build with -v).  With bmake, if a parallel build 
fails I have to rerun the build without -j, because the output is 
interleaved with succeeding jobs and it's difficult to see what actually 
failed.  With ninja, the output is from each failed job, with no 
interleaving.


David

Re: -CURRENT compilation time

[Mark Millard via freebsd-current]

> 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 the upstream CMake + Ninja build system is 
> *significantly* faster on a decent multicore machine than the FreeBSD 
> bmake-based in-tree version.

Just examples of llvm12 builds from my checking this . . .

poudriere-devel llvm12 buil times, nothing else being built, all
prerequisites already built (not that such are trivial):


amd64 ThreadRipper 1950X with 128 GiByte of RAM, optane 1.4T media, 32 FreeBSD 
cpus:

[00:00:07] [01] [00:00:00] Building devel/llvm12 | llvm12-12.0.1_4
[00:22:54] [01] [00:22:47] Finished devel/llvm12 | llvm12-12.0.1_4: Success

for:

---Begin OPTIONS List---
===> The following configuration options are available for llvm12-12.0.1_4:
 BE_AMDGPU=on: AMD GPU backend (required by mesa)
 CLANG=on: Build clang
 COMPILER_RT=on: Sanitizer libraries
 DOCS=on: Build and/or install documentation
 EXTRAS=on: Extra clang tools
 GOLD=on: Build the LLVM Gold plugin for LTO
 LIT=on: Install lit and FileCheck test tools
 LLD=on: Install lld, the LLVM linker
 LLDB=on: Install lldb, the LLVM debugger
 OPENMP=on: Install libomp, the LLVM OpenMP runtime library
 PYCLANG=off: Install python bindings to libclang
> Options available for the single BACKENDS: you have to select exactly one 
of them
 BE_FREEBSD=off: Backends for FreeBSD architectures
 BE_NATIVE=on: Backend(s) for this architecture (X86)
 BE_STANDARD=off: All non-experimental backends
===> Use 'make config' to modify these settings
---End OPTIONS List---

Note the BE_NATIVE use. Also poudriere.conf has:

ZPOOL=zoptb
USE_TMPFS=yes
ALLOW_MAKE_JOBS=yes

For reference:

# uname -apKU
FreeBSD amd64_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #1 
releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:28:31 PDT 2021 
root@amd64_ZFS:/usr/obj/BUILDs/13_0R-amd64-nodbg-clang/usr/13_0R-src/amd64.amd64/sys/GENERIC-NODBG
  amd64 amd64 1300139 1300139

The swap/paging space stayed unused.

aarch64 Honycomb with 64 GiByte of RAM, optane 480 GiByte media, 16 FreeBSD 
cpus:

[00:00:15] [01] [00:00:00] Building devel/llvm12 | llvm12-12.0.1_4
[00:58:07] [01] [00:57:52] Finished devel/llvm12 | llvm12-12.0.1_4: Success

for:

---Begin OPTIONS List---
===> The following configuration options are available for llvm12-12.0.1_4:
 BE_AMDGPU=on: AMD GPU backend (required by mesa)
 CLANG=on: Build clang
 DOCS=on: Build and/or install documentation
 EXTRAS=on: Extra clang tools
 LIT=on: Install lit and FileCheck test tools
 LLD=on: Install lld, the LLVM linker
 OPENMP=on: Install libomp, the LLVM OpenMP runtime library
 PYCLANG=off: Install python bindings to libclang
> Options available for the single BACKENDS: you have to select exactly one 
of them
 BE_FREEBSD=off: Backends for FreeBSD architectures
 BE_NATIVE=on: Backend(s) for this architecture (AArch64)
 BE_STANDARD=off: All non-experimental backends
===> Use 'make config' to modify these settings
---End OPTIONS List---

Note the BE_NATIVE use. Also poudriere.conf has:

ZPOOL=zopt0
USE_TMPFS="data"
ALLOW_MAKE_JOBS=yes

For reference:

# uname -apKU
FreeBSD CA72_16Gp_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 
releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
  arm64 aarch64 1300139 1300139

The swap/paging space stayed unused.



I've not yet figured out a good way to time just an analogous
subset of buildworld . It would need to be stable/13 or main
[so: 14] targetted to involve building an llvm12 based set of
material. releng/13.0 is llvm11 based.

One point is that likely the system builds libc++ and such
but devel/llvm12 does not: devel/llvm12 likely is bound to the
system libc++ and such. This may make "analogous subset of
buildworld" harder to isolate.

So I've not made it to well-measured differences in time-used
yet.


> 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 CMake) build system without having to recreate 
> it, and be able to use ninja, to build.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

Re: -CURRENT compilation time

[Stefan Esser]

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 + Ninja build system is
> *significantly* faster on a decent multicore machine than the FreeBSD
> bmake-based in-tree version.
> 
> 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
> CMake) build system without having to recreate it, and be able to use ninja, 
> to
> build.

Wouldn't this break META_MODE?

I'd rather be able to continue building the world within a few minutes
(generally much less than 10 minutes, as long as there is no major LLVM
upgrade) than have a faster LLVM build and then a slower build of the world ...

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: -CURRENT compilation time

[Dave Cottlehuber]

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 CMake) build system without having to recreate 
> it, and be able to use ninja, to build.

This would be a worthy FreeBSD foundation project IMHO.

A+
Dave

Re: -CURRENT compilation time

[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 + Ninja build system is 
*significantly* faster on a decent multicore machine than the FreeBSD 
bmake-based in-tree version.


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 CMake) build system without having to recreate 
it, and be able to use ninja, to build.


David

Re: -CURRENT compilation time

[Ronald Klop]

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 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 deployment images.  You actually don't need to build it at all, 
you can use an external toolchain to skip the first build and you can compile 
WITHOUT_TOOLCHAIN  to avoid building the version that's installed and then 
install a toolchain from packages:

https://wiki.freebsd.org/ExternalToolchain

David

 






Hi,

I'm very interested in a base without llvm because of compile times. So I tried 
this in a jail with 14-current and pkg llvm12 installed.

/etc/make.conf:
WITHOUT_TOOLCHAIN=yes
CROSS_TOOLCHAIN=llvm12

Buildworld, installworld and etcupdate went fine. "yes | make delete-old" 
removes the toolchain from base.
Afterwards you can't do buildworld anymore.

# make buildworld
sh: cc: not found
make: "/home/ronald/dev/freebsd/share/mk/bsd.compiler.mk" line 200: warning: "cc -v 2>&1 | 
grep "gcc version"" returned non-zero status
make: "/home/ronald/dev/freebsd/share/mk/bsd.compiler.mk" line 204: Unable to 
determine compiler type for CC=cc.  Consider setting COMPILER_TYPE.

What am I missing?

Regards,
Ronald.

Re: -CURRENT compilation time

[Wolfram Schneider]

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 LLVM twice only if you are actively
> debugging LLVM reproduceable deployment images.  You actually don't need
> to build it at all, you can use an external toolchain to skip the first
> build and you can compile WITHOUT_TOOLCHAIN  to avoid building the
> version that's installed and then install a toolchain from packages:
>
> https://wiki.freebsd.org/ExternalToolchain

I did a test on a 16 core (32 VCPU) machine (Intel(R) Xeon(R) CPU
E5-2630 v3 @ 2.40GHz).

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.

time make -j16 buildworld
--
>>> World build completed on Mon Sep  6 12:00:45 UTC 2021
>>> World built in 2862 seconds, ncpu: 32, make -j16
--
 2862.04 real 41234.87 user  1582.66 sys

time make -j16 WITHOUT_TOOLCHAIN=yes buildworld
--
>>> World build completed on Mon Sep  6 11:32:41 UTC 2021
>>> World built in 1181 seconds, ncpu: 32, make -j16
--
 1180.73 real 16076.27 user   988.73 sys

-Wolfram

-- 
Wolfram Schneider  https://wolfram.schneider.org

Re: -CURRENT compilation time

[Wolfram Schneider]

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
> still in stage 4.2 (building libraries). Through occasional glancing
> at the screen over the weekend, it seems obvious to me that the
> compilation time is utterly dominated by LLVM.  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).
>
> So OK, my CPU is not the most powerful out there but it's still decent [1].
>
> So I have a couple of questions coming to my mind:
> 1. Is there any optimization I could benefit from? (I'm sure there's a
> knob to use the existing compiler instead of building a
> cross-compiler.)
> 2. More generally, isn't this compilation time not considered as a
> problem for developers? This seems to terribly slow down the iteration
> time for people working on the build system. I wouldn't be surprised
> if this drove people away from working on/improving that area.
>
> [1] 
> https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz=2671

Hi,

I ran buildworld yesterday on a 3 CPU VM (AMD EPYC 2.4GHz) and the
runtime was 2h. We spent most of the time in "stage 4.2: building
libraries", in my case 62% of the CPU time and 75% of the real time.

I guess the build time on your laptop should be around 6 hours if
everything is ok.


time make -j $(sysctl -n hw.ncpu) buildworld  > log.buildworld 2>&1

tail -n 5 log.buildworld
--
>>> World build completed on Sat Sep  4 20:58:00 UTC 2021
>>> World built in 7235 seconds, ncpu: 3, make -j3
--
 7235.61 real 20527.30 user   915.88 sys

egrep '>>> stage| real ' log.buildworld
>>> stage 1.1: legacy release compatibility shims
0.28 real 0.18 user 0.10 sys
>>> stage 1.2: bootstrap tools
  165.99 real   472.58 user11.56 sys
>>> stage 2.1: cleaning up the object tree
   21.47 real36.96 user14.14 sys
   15.87 real29.14 user11.87 sys
>>> stage 2.3: build tools
2.42 real 3.79 user 0.62 sys
>>> stage 3: cross tools
9.92 real18.49 user 1.75 sys
>>> stage 3.1: recording build metadata
0.07 real 0.01 user 0.06 sys
>>> stage 4.1: building includes
   16.62 real36.46 user 9.48 sys
>>> stage 4.2: building libraries
 5440.89 real 15724.60 user   482.58 sys
>>> stage 4.3: building lib32 shim libraries
  615.91 real  1654.77 user   164.58 sys
>>> stage 4.4: building everything
  937.23 real  2540.06 user   205.47 sys

-Wolfram

-- 
Wolfram Schneider  https://wolfram.schneider.org

Re: -CURRENT compilation time

[Jeffrey Bouquet]

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 build LLVM twice only if you are actively 
> debugging LLVM reproduceable deployment images.  You actually don't need 
> to build it at all, you can use an external toolchain to skip the first 
> build and you can compile WITHOUT_TOOLCHAIN  to avoid building the 
> version that's installed and then install a toolchain from packages:
> 
> https://wiki.freebsd.org/ExternalToolchain
> 
> David


If only that suggestion was topmost in UPDATING and repeated in each
security advisory... 

Re: -CURRENT compilation time

[David Chisnall]

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 deployment images.  You actually don't need 
to build it at all, you can use an external toolchain to skip the first 
build and you can compile WITHOUT_TOOLCHAIN  to avoid building the 
version that's installed and then install a toolchain from packages:


https://wiki.freebsd.org/ExternalToolchain

David

Re: -CURRENT compilation time

[Guido Falsi via freebsd-current]

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 occasional glancing
at the screen over the weekend, it seems obvious to me that the
compilation time is utterly dominated by LLVM.  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).

So OK, my CPU is not the most powerful out there but it's still decent [1].

So I have a couple of questions coming to my mind:
1. Is there any optimization I could benefit from? (I'm sure there's a
knob to use the existing compiler instead of building a
cross-compiler.)


I'm routinely compiling head once a month or so on an "i7-6700 CPU @ 
3.40GHz" (from dmesg), slightly more powerful than an i5 but this is a 
relatively old one so not top notch anymore. It usually takes less than 
4 hours. I also build a NanoBSD image from scratch from time to time to 
an even older i5, which takes a little longer, but always under 6 hours, 
so the build times you report look anomalous.


So as already suggested make sure yiu are using parallel make jobs (-j 
option to make) and memory is large enough (I think you need at least 2 
GiB for make job is the minimum to not risk thrashing.


You should really enable meta mode (look for WITH_META_MODE in 
src.conf(5)). It will not help the first time but will help a lot in 
future recompilations with an already populated /usr/obj.


You could also investigate using ccache, which again will only help for 
successive rebuilds, and will consume a fair amount of disk space.


Another consideration, my builds are happening on SSD disks, with swap 
on SSD, if you have everything on spinning media that is also a slowing 
factor. If you have plenty of ram you could build in ram, which is what 
I'm doing with poudriere for ports and it really speeds things up (even 
SSD disks tend to get slower when hit with a constant high load of mixed 
read/write accesses, which poudriere with parallel builds sometime causes)


Hope this helps!

--
Guido Falsi 

Re: -CURRENT compilation time

[Michael Schuster]

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 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 the weekend, it seems obvious to me that the
> compilation time is utterly dominated by LLVM.


Do you actually measure anything?
have you looked into what your I/O is doing? How about swap?

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).
>
> So OK, my CPU is not the most powerful out there but it's still decent [1].
>

I didn't check the specs: how many cores does your box have, and how many
are you actually using (-j N)? IME, htop gives a good idea of how busy the
CPUs really are.

> So I have a couple of questions coming to my mind:
> 1. Is there any optimization I could benefit from? (I'm sure there's a
> knob to use the existing compiler instead of building a
> cross-compiler.)
>

look at the build man page (https://www.freebsd.org/cgi/man.cgi?build(7))
for some tips on how to configure your environment.

2. More generally, isn't this compilation time not considered as a
> problem for developers? This seems to terribly slow down the iteration
> time for people working on the build system. I wouldn't be surprised
> if this drove people away from working on/improving that area.
>
> [1]
> https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz=2671
>
> Cheers,
> --
> Jeremie Le Hen
> j...@freebsd.org
>
>
regards
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

-CURRENT compilation time

[Jeremie Le Hen]

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 the weekend, it seems obvious to me that the
compilation time is utterly dominated by LLVM.  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).

So OK, my CPU is not the most powerful out there but it's still decent [1].

So I have a couple of questions coming to my mind:
1. Is there any optimization I could benefit from? (I'm sure there's a
knob to use the existing compiler instead of building a
cross-compiler.)
2. More generally, isn't this compilation time not considered as a
problem for developers? This seems to terribly slow down the iteration
time for people working on the build system. I wouldn't be surprised
if this drove people away from working on/improving that area.

[1] 
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz=2671

Cheers,
-- 
Jeremie Le Hen
j...@freebsd.org

RE: undefined symbol: random_source_register during kernel compilation

[M - Krasznai András]

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 (and on 
again) in /etc/src.conf, but I suppose that if I switch it BACK, thatis if I 
want it to compile casper again (remove the WITHOUT_CASPER=YES line from 
src.conf, e.g.), then the sources for casper should be there somewhere in my 
freshly synchonized source tree.

(and it is: libcasper.h is in /usr/src/lib/libcasper/libcasper  but compilation 
supposes that it has already been installed into /usr/include).

Now I try to compile GENERIC with my original src.conf, which switches off the 
CASPER, and see what happens.

rgds
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@freebsd.org
Tárgy: Re: undefined symbol: random_source_register during kernel compilation



On 7/18/19 5:21 AM, M - Krasznai András wrote:
> Hi
>
>
> I have been trying to compile a freebsd-current kernel since the 16th of 
> July, and keep getting the following error during "make buildkernel":
>
>
> Building /usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full
> linking kernel.full
> ld: error: undefined symbol: random_source_register
>>>> referenced by ivy.c:108 (/usr/src/sys/dev/random/ivy.c:108)
>>>>ivy.o:(rdrand_modevent)
> ld: error: undefined symbol: random_source_deregister
>>>> referenced by ivy.c:115 (/usr/src/sys/dev/random/ivy.c:115)
>>>>ivy.o:(rdrand_modevent)
> ld: error: undefined symbol: random_source_register
>>>> referenced by nehemiah.c:124 (/usr/src/sys/dev/random/nehemiah.c:124)
>>>>nehemiah.o:(nehemiah_modevent)
> ld: error: undefined symbol: random_source_deregister
>>>> referenced by nehemiah.c:133 (/usr/src/sys/dev/random/nehemiah.c:133)
>>>>nehemiah.o:(nehemiah_modevent)
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/G13NEW
> .ERROR_TARGET='kernel.full'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full.meta'
> .MAKE.LEVEL='2'
> MAKEFILE=''
> .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.conf files as well as my kernel configuration file was not 
> changed since a couple of months (since I installed freebsd-current).
are you able to build GENERIC?  if so might be worth looking at the 
delta's b/w GENERIC and your custom configuration and trying to zero in 
on what may be causing this to fail.

-p

-- 
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: undefined symbol: random_source_register during kernel compilation

[M - Krasznai András]

Hi, thanks for the advice.

Now I emptied the /usr/src and /usr/obj directories, downloaded the CURRENT 
sources again, and removed the /etc/src.conf file. 
I compile the GENERIC kernel now, /etc/make.conf contains 


KERNCONF=GENERIC
MK_PROFILE=NO
DEFAULT_VERSIONS+=linux=c6
MALLOC_PRODUCTION=YES
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@freebsd.org
Tárgy: Re: undefined symbol: random_source_register during kernel compilation



On 7/18/19 5:21 AM, M - Krasznai András wrote:
> Hi
>
>
> I have been trying to compile a freebsd-current kernel since the 16th of 
> July, and keep getting the following error during "make buildkernel":
>
>
> Building /usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full
> linking kernel.full
> ld: error: undefined symbol: random_source_register
>>>> referenced by ivy.c:108 (/usr/src/sys/dev/random/ivy.c:108)
>>>>ivy.o:(rdrand_modevent)
> ld: error: undefined symbol: random_source_deregister
>>>> referenced by ivy.c:115 (/usr/src/sys/dev/random/ivy.c:115)
>>>>ivy.o:(rdrand_modevent)
> ld: error: undefined symbol: random_source_register
>>>> referenced by nehemiah.c:124 (/usr/src/sys/dev/random/nehemiah.c:124)
>>>>nehemiah.o:(nehemiah_modevent)
> ld: error: undefined symbol: random_source_deregister
>>>> referenced by nehemiah.c:133 (/usr/src/sys/dev/random/nehemiah.c:133)
>>>>nehemiah.o:(nehemiah_modevent)
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/G13NEW
> .ERROR_TARGET='kernel.full'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full.meta'
> .MAKE.LEVEL='2'
> MAKEFILE=''
> .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.conf files as well as my kernel configuration file was not 
> changed since a couple of months (since I installed freebsd-current).
are you able to build GENERIC?  if so might be worth looking at the 
delta's b/w GENERIC and your custom configuration and trying to zero in 
on what may be causing this to fail.

-p

-- 
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: undefined symbol: random_source_register during kernel compilation

[Pete Wright]

On 7/18/19 5:21 AM, M - Krasznai András wrote:

Hi


I have been trying to compile a freebsd-current kernel since the 16th of July, and keep 
getting the following error during "make buildkernel":


Building /usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full
linking kernel.full
ld: error: undefined symbol: random_source_register

referenced by ivy.c:108 (/usr/src/sys/dev/random/ivy.c:108)
   ivy.o:(rdrand_modevent)

ld: error: undefined symbol: random_source_deregister

referenced by ivy.c:115 (/usr/src/sys/dev/random/ivy.c:115)
   ivy.o:(rdrand_modevent)

ld: error: undefined symbol: random_source_register

referenced by nehemiah.c:124 (/usr/src/sys/dev/random/nehemiah.c:124)
   nehemiah.o:(nehemiah_modevent)

ld: error: undefined symbol: random_source_deregister

referenced by nehemiah.c:133 (/usr/src/sys/dev/random/nehemiah.c:133)
   nehemiah.o:(nehemiah_modevent)

*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/G13NEW
.ERROR_TARGET='kernel.full'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full.meta'
.MAKE.LEVEL='2'
MAKEFILE=''
.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.conf files as well as my kernel configuration file was not 
changed since a couple of months (since I installed freebsd-current).
are you able to build GENERIC?  if so might be worth looking at the 
delta's b/w GENERIC and your custom configuration and trying to zero in 
on what may be causing this to fail.


-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

undefined symbol: random_source_register during kernel compilation

[M - Krasznai András]

Hi


I have been trying to compile a freebsd-current kernel since the 16th of July, 
and keep getting the following error during "make buildkernel":


Building /usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full
linking kernel.full
ld: error: undefined symbol: random_source_register
>>> referenced by ivy.c:108 (/usr/src/sys/dev/random/ivy.c:108)
>>>   ivy.o:(rdrand_modevent)

ld: error: undefined symbol: random_source_deregister
>>> referenced by ivy.c:115 (/usr/src/sys/dev/random/ivy.c:115)
>>>   ivy.o:(rdrand_modevent)

ld: error: undefined symbol: random_source_register
>>> referenced by nehemiah.c:124 (/usr/src/sys/dev/random/nehemiah.c:124)
>>>   nehemiah.o:(nehemiah_modevent)

ld: error: undefined symbol: random_source_deregister
>>> referenced by nehemiah.c:133 (/usr/src/sys/dev/random/nehemiah.c:133)
>>>   nehemiah.o:(nehemiah_modevent)
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/G13NEW
.ERROR_TARGET='kernel.full'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full.meta'
.MAKE.LEVEL='2'
MAKEFILE=''
.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.conf files as well as my kernel configuration file was not 
changed since a couple of months (since I installed freebsd-current).

rgds

?





___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Lev Serebryakov]

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, consumer-grade, but really good one!).

 I've tuned down TRIMs with

vfs.zfs.per_txg_dirty_frees_percent=10
vfs.zfs.free_max_blocks=1000
vfs.zfs.vdev.trim_max_active=4

And it MOSTLY solved problem: there are some freezing from time to time (and
strange consumption of CPU by low-profile threads) with these settings.

 When I've disabled TRIM completely all freezes are gone, and low-profile
threads consume tenths of percent of CPU, as it is intended.

-- 
Best regards,
 Levmailto:l...@freebsd.org

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Lev Serebryakov]

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 kernel via source update. Now I'm trying to
update it second time without luck.

 First upgrade was not so painful, as far as I can remember :-)

> Can you please narrow the problem down to a specific kernel revision?
 I'm still not sure it is software or hardware problem.

> Most importantly, does this show up with a 12.0 kernel?
I didn't tried 12 kernel on this hardware.

> I'm running one amd box and a number of intel boxes with various cpus,
> no issues.
 Me too, but this is only one box which have 13 and try to compile
 something, all other boxes are either 11/12 or are small NanoBSD installations
 without toolchain...

-- 
Best regards,
 Levmailto:l...@freebsd.org

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mateusz Guzik]

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 upsmon's connection to remote upsd
> flickers! Unbelievable.
>
>  Looks like each next compiler invocation is slower and more stressful than
> previous one.
>

Is this a fresh install?

Can you please narrow the problem down to a specific kernel revision?
Most importantly, does this show up with a 12.0 kernel?

I'm running one amd box and a number of intel boxes with various cpus,
no issues.

-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Eugene Grosbein]

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 something of this helps, try going back to defaults and then disable 
power-saving settings, if any.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Lev Serebryakov]

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 kern.eventtimer.periodic=1 instead of default 0.
 Nothing helps. I've tried periodic=1 and replace hardware and time with HPT
 (from TSC-Low and LAPIC), but system still "sticky" with single-job build
 and unresposnive with multiple-job build, and still there is strange bursts
 of CPU consumption from threads and processes which should be low-profile.

> If something of this helps, try going back to defaults and then disable 
> power-saving settings, if any.
 I'll try to disable C2/C3 and turn off Turbo as next step...

-- 
Best regards,
 Levmailto:l...@freebsd.org

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Lev Serebryakov]

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! Unbelievable.

 Looks like each next compiler invocation is slower and more stressful than
previous one.

-- 
Best regards,
 Levmailto:l...@freebsd.org

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Lev Serebryakov]

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
> system is idle there never will be "intr{swi4: clock (0)}" consuming 55% CPU
> for one "frame" or sshd, or screen itself.
 Like this. This system doesn't have any significant network traffic now —
only one ssh connection, which is used as console. And 62.3% for network
card. WTF?!

  PID USERNAMEPRI NICE   SIZERES STATEC   TIMEWCPU COMMAND
20128 root1010   104M74M CPU1 1   0:31 100.00% cc
0 root-76-  0  4608K -2  53:25  62.23% 
kernel{if_config_tqg_0}
   11 root-60-  0   240K WAIT 0  25:45  24.89% intr{swi4: 
clock (0)}
9 root -8-  0   160K tx->tx   0   7:38  24.88% 
zfskern{txg_thread_enter}
  995 root 24017M  7676K select   1   2:20  12.44% sendmail
13791 root 24024M15M select   0   0:04  12.44% make




-- 
Best regards,
 Levmailto:l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Waitman Gobble]

‐‐‐ 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, like clock software
> > interrupt (!) could consume large amount of CPU for short periods time. When
> > system is idle there never will be "intr{swi4: clock (0)}" consuming 55% CPU
> > for one "frame" or sshd, or screen itself.
>
> Like this. This system doesn't have any significant network traffic now —
> only one ssh connection, which is used as console. And 62.3% for network
> card. WTF?!
>
> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 20128 root 101 0 104M 74M CPU1 1 0:31 100.00% cc
> 0 root -76 - 0 4608K - 2 53:25 62.23% kernel{if_config_tqg_0}
> 11 root -60 - 0 240K WAIT 0 25:45 24.89% intr{swi4: clock (0)}
> 9 root -8 - 0 160K tx->tx 0 7:38 24.88% zfskern{txg_thread_enter}
>
> 995 root 24 0 17M 7676K select 1 2:20 12.44% sendmail
> 13791 root 24 0 24M 15M select 0 0:04 12.44% make
>
>
> -
>
> Best regards,
> Lev mailto:l...@freebsd.org
>
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

I had super slow build for r341270, but I thought it was because I accidentally 
left WITNESS option set.

I killed it after about 10 hours, booted to single user and rebuilt kernel 
there.

Waitman

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Lev Serebryakov]

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 too. Here is statistics from top when single-job kernel
build is in action. A lot of free memory, small ARC, too much CPU is
consumed by interrupts, but there is free CPU clocks:

last pid: 19488;  load averages:  7.03,  5.35,  5.10  up 0+14:43:04  15:09:55
417 threads:   7 running, 395 sleeping, 15 waiting
CPU 0: 50.0% user,  0.0% nice,  0.0% system, 16.4% interrupt, 33.6% idle
CPU 1: 16.4% user,  0.0% nice, 16.8% system,  0.0% interrupt, 66.8% idle
CPU 2:  0.0% user,  0.0% nice, 33.2% system,  0.0% interrupt, 66.8% idle
CPU 3: 33.2% user,  0.0% nice, 33.2% system,  0.0% interrupt, 33.6% idle
Mem: 28M Active, 315M Inact, 2076K Laundry, 2541M Wired, 1129K Buf, 5031M Free
ARC: 1025M Total, 197M MFU, 415M MRU, 514K Anon, 20M Header, 392M Other
 189M Compressed, 563M Uncompressed, 2.98:1 Ratio
Swap: 16G Total, 16G Free




-- 
Best regards,
 Levmailto:l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Lev Serebryakov]

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. "make -j *1* buildkernel" takes
forever and each compiler invocation takes up to 10 seconds. For example,
I've clocked compilation of sys/dev/aic7xxx/aic7xxx_93cx6.c by stopwatch and
it takes 9 seconds. Please note, it is SINGLE JOB build. If I run "make
-j4" it will be much longer for each compiler out of 4. And all this time
"cc" / "c++" consume 100% of CPU.

 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!

 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
system is idle there never will be "intr{swi4: clock (0)}" consuming 55% CPU
for one "frame" or sshd, or screen itself.

 I'm completely lost. Is it problem of software? Hardware? If it is
hardware problem what should I blame?

 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.

-- 
Best regards,
 Lev  mailto:l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Compilation failure of the kernel for drm-next

[Mylan Connolly]

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. The only issue now is I cannot adjust the backlight.

Thanks again for all the help

​Mylan

‐‐‐ Original Message ‐‐‐

On February 27, 2018 3:51 AM, Greg V  wrote:

> 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 working on the repository and will see when new issues are
> > 
> > reported.
> > 
> > as of now your best to to use or test out the drm-next bits is to run
> > 
> > a recent 12-CURRENT with no patches applied.  then you can build the
> > 
> > port or package via the ports tree under graphics/drm-next-kmod.  it
> > 
> > currently runs on my end under 12-CURRENT and 11-STABLE.
> 
> Yeah, and the issue tracker for drm-next-kmod is
> 
> https://github.com/FreeBSDDesktop/kms-drm/issues
> 
> NOT https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Compilation failure of the kernel for drm-next

[Greg V]

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 working on the repository and will see when new issues are 
reported.


as of now your best to to use or test out the drm-next bits is to run 
a recent 12-CURRENT with no patches applied.  then you can build the 
port or package via the ports tree under graphics/drm-next-kmod.  it 
currently runs on my end under 12-CURRENT and 11-STABLE.

Yeah, and the issue tracker for drm-next-kmod is

https://github.com/FreeBSDDesktop/kms-drm/issues

NOT https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Compilation failure of the kernel for drm-next

[Pete Wright]

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 when new issues are 
reported.


as of now your best to to use or test out the drm-next bits is to run a 
recent 12-CURRENT with no patches applied.  then you can build the port 
or package via the ports tree under graphics/drm-next-kmod.  it 
currently runs on my end under 12-CURRENT and 11-STABLE.


cheers,
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Compilation failure of the kernel for drm-next

[Mylan Connolly]

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 try to compile the kernel (using the command `make kernel`) I get the 
following error. Let me know if there's anything else I can do to assist.

/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe 
'-DKBUILD_MODNAME="i915kms"' -include /usr/src/sys/dev/drm/drm_os_config.h 
-march=skylake  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-I/usr/src/sys/compat/linuxkpi/dummy/include 
-I/usr/src/sys/compat/linuxkpi/gplv2/include 
-I/usr/src/sys/compat/linuxkpi/common/include 
-I/usr/src/sys/compat/linuxkpi/common/include/uapi -DHAVE_KERNEL_OPTION_HEADERS 
-include /usr/obj/usr/src/amd64.amd64/sys/GENERIC/opt_global.h -I. 
-I/usr/src/sys -fno-common -g -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/amd64.amd64/sys/GENERIC   -MD  
-MF.depend.intel_freebsd.o -MTintel_freebsd.o -mcmodel=kernel -mno-red-zone 
-mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes -Wmissing-prototype
 s -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare 
-Wno-error-empty-body -Wno-error-parentheses-equality 
-Wno-error-unused-function -Wno-error-pointer-sign 
-Wno-error-shift-negative-value -Wno-error-address-of-packed-member 
-Wno-pointer-arith -Wno-format  -mno-aes -mno-avx  -std=iso9899:1999 -c 
/usr/src/sys/dev/drm/i915/intel_freebsd.c -o intel_freebsd.o

/usr/src/sys/dev/drm/i915/intel_freebsd.c:203:5: error: use of undeclared 
identifier 'VM_WAIT'; did you mean 'VM_LAST'?

VM_WAIT;

^~~

VM_LAST

/usr/src/sys/sys/systm.h:81:50: note: 'VM_LAST' declared here

VM_GUEST_VMWARE, VM_GUEST_KVM, VM_GUEST_BHYVE, VM_LAST };

   ^

/usr/src/sys/dev/drm/i915/intel_freebsd.c:203:5: error: expression result 
unused [-Werror,-Wunused-value]

VM_WAIT;

^~~

2 errors generated.

*** [intel_freebsd.o] Error code 1

make[6]: stopped in /usr/src/sys/modules/drm/i915/i915kms

1 error

make[6]: stopped in /usr/src/sys/modules/drm/i915/i915kms

*** [all_subdir_drm/i915/i915kms] Error code 2

make[5]: stopped in /usr/src/sys/modules/drm/i915

1 error

make[5]: stopped in /usr/src/sys/modules/drm/i915

*** [all_subdir_drm/i915] Error code 2

make[4]: stopped in /usr/src/sys/modules/drm

1 error

make[4]: stopped in /usr/src/sys/modules/drm

*** [all_subdir_drm] Error code 2

make[3]: stopped in /usr/src/sys/modules

1 error

make[3]: stopped in /usr/src/sys/modules

*** [modules-all] Error code 2

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC

1 error

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC

*** [buildkernel] Error code 2

make[1]: stopped in /usr/src

1 error

make[1]: stopped in /usr/src

*** [buildkernel] Error code 2

make: stopped in /usr/src

1 error

make: stopped in /usr/src

Mylan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r323289 breaks i386 kernel compilation

[Michael Butler]

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]

printf("%s: 0x%lx: !valid | !present\n", __func__, misc);
  ~~~  ^~~~
  %llx
/usr/src/sys/x86/x86/mca.c:991:43: error: format specifies type 
'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long 
long') [-Werror,-Wformat]

printf("%s: 0x%lx: locked\n", __func__, misc);
  ~~~   ^~~~
  %llx
/usr/src/sys/x86/x86/mca.c:1000:58: error: format specifies type 
'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long 
long') [-Werror,-Wformat]
printf("%s: 0x%lx: count already enabled\n", __func__, 
misc);

  ~~~  ^~~~
  %llx
3 errors generated.
*** [mca.o] Error code 1
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r307866 compilation problem

[Konstantin Belousov]

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
> Index: cpu_machdep.c
> ===
> --- cpu_machdep.c   (revision 307875)
> +++ cpu_machdep.c   (working copy)
> @@ -540,9 +540,9 @@
>   nmi_call_kdb(u_int cpu, u_int type, struct trapframe *frame, bool 
> do_panic)
>   {
> 
> +#ifdef KDB
>  /* machine/parity/power fail/"kitchen sink" faults */
>  if (isa_nmi(frame->tf_err) == 0) {
> -#ifdef KDB
>  /*
>   * NMI can be hooked up to a pushbutton for debugging.
>   */
Um, no.  isa_nmi() should be checked and panic avoided regardless
of the panic_on_nmi setting, if no hw error was reported.  It is
#endif that was misplaced.

This and another change, are committed as r307880.

Thank you for the report.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r307866 compilation problem

[Michael Butler]

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_machdep.c   (revision 307875)
+++ cpu_machdep.c   (working copy)
@@ -540,9 +540,9 @@
 nmi_call_kdb(u_int cpu, u_int type, struct trapframe *frame, bool 
do_panic)

 {

+#ifdef KDB
/* machine/parity/power fail/"kitchen sink" faults */
if (isa_nmi(frame->tf_err) == 0) {
-#ifdef KDB
/*
 * NMI can be hooked up to a pushbutton for debugging.
 */
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r303643 breaks non-SMP compilation

[Guido Falsi]

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 may be,
>>
> 
> Indeed, fixed in r303655.
> 
> Thanks for reporting.
> 

I've noticed another failure in the same file, caused by r303643.

It's failing to compile here due to errors about SYSINIT(9), it looks
like #include  is missing.

I have made a local patch which compiles and afdter a reboot seems to
work fine:

Index: head/sys/kern/kern_sx.c
===
--- head/sys/kern/kern_sx.c (revision 303658)
+++ head/sys/kern/kern_sx.c (working copy)
@@ -58,6 +58,7 @@

 #if defined(SMP) && !defined(NO_ADAPTIVE_SX)
 #include 
+#include 
 #endif

 #ifdef DDB


-- 
Guido Falsi <m...@madpilot.net>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

amd64-xtoolchain-gcc: small kernel compilation issue

[Andriy Gapon]

/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 amd64-xtoolchain-gcc-0.1, which seems to install gcc
version 5.3.0, and optimization level set to O1.

It seems that in that case gcc is not smart enough to figure out that if
VM_MEMSEG_NAME(mseg) is not NULL in a condition, then it can not be NULL
in a block guarded by the condition.

So, the following trivial patch should not be necessary but makes gcc a
bit happier:
--- a/sys/amd64/vmm/vmm_dev.c
+++ b/sys/amd64/vmm/vmm_dev.c
@@ -258,7 +258,7 @@ alloc_memseg
if (VM_MEMSEG_NAME(mseg)) {
sysmem = false;
name = malloc(SPECNAMELEN + 1, M_VMMDEV, M_WAITOK);
-   error = copystr(VM_MEMSEG_NAME(mseg), name, SPECNAMELEN + 1, 0);
+   error = copystr(mseg->name, name, SPECNAMELEN + 1, 0);
if (error)
goto done;
}


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r303643 breaks non-SMP compilation

[Mateusz Guzik]

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 for reporting.
-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r303643 breaks non-SMP compilation

[Michael Butler]

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/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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

[Simon J. Gerraty]

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 buildenv TARGET=powerpc 
> TARGET_ARCH=powerpc
> Entering world for powerpc:powerpc
> $ cd cddl/usr.sbin/dtrace/tests/common/json
> $ make -V.OBJDIR
> /scratch/tmp/ngie/obj//powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json
> $ make -VMAKEOBJDIRPREFIX
> /scratch/tmp/ngie/obj//powerpc.powerpc
> $ make depend
> (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
> /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
> _RECURSING_PROGS=  PROG=tst.usdt.exe  depend)

If you are doing this on current (ie MAKE_VERSION==20151020), adding -w
would be useful, since will report entering src and obj dirs.

> $ make all
> (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
> /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
> _RECURSING_PROGS=  PROG=tst.usdt.exe )
> dtrace -C -x nolibs -G -o usdt.o -s 
> /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
>  tst.usdt.o
> dtrace: failed to link script 
> /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>  incorrect ELF machine type for object file: tst.usdt.o

> Stop.
> make[2]: stopped in 
> /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json
> $ make -V.PATH

what dir do you execute that in?
I'm *guessing* cddl/usr.sbin/dtrace/tests/common/json.

It's actually quite useful when reporting/describing problems to do
everything from src eg.

make -w -C cddl/usr.sbin/dtrace/tests/common/json

leaves very little room for confusion.


> . /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json 
> /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json

What else do you expect in .PATH?
I didn't see anything in the Makefile or ../../Makefile.inc1 to add
anything else

You may also find it useful to set MAKE_PRINT_VAR_ON_ERROR
to a list of variables - that will be reported when make dies.
eg.

MAKE_PRINT_VAR_ON_ERROR=".CURDIR .OBJDIR MACHINE MACHINE_ARCH .PATH"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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]

> 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 x64 object when I specify powerpc/powerpc — and more 
>> importantly, why is the object not being put in obj.powerpc?
>>  I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
>> tinderbox".
> 
> Is it possible that the file is left over from a previous build (of amd64?)
> 
> Does your log show it being built?
> 
> 
>> dtrace -C -x nolibs -G -o usdt.o -s 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
>> tst.usdt.o
>> dtrace: failed to link script 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>  incorrect ELF machine type for object file: tst.usdt.o
>> *** Error code 1
>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
>> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

Still running into issues on ref11-amd64:

cc1: error: unrecognized command line option "-m64"
dtrace: failed to compile script 
/scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
 Preprocessor failed to process input program
--- usdt.h ---
*** [usdt.h] Error code 1

Let’s see what happens if I use make buildenv

$ env MAKEOBJDIRPREFIX=/scratch/tmp/$USER/obj make buildenv TARGET=mips 
TARGET_ARCH=mips
Entering world for mips:mips
$ make -VMAKEOBJDIRPREFIX
/scratch/tmp/ngie/obj/mips.mips
$ which dtrace
/usr/sbin/dtrace

Uh… yeah… running the copy from the build host is no bueno. So, that root 
causes that issue. I’ll file a bug for that (dtrace needs to be built as a 
bootstrap/cross tool). The -m64 issue is because it’s compiled for amd64 and is 
running arguments that are only supposed to “work” for x86 platforms (in 
reality, there’s also no reason why -m32/-m64 need to be passed to 
${CC}/${CPP}):

1256 #ifdef illumos
1257 #ifdef __x86
1258 /*
1259  * On x86 systems, __i386 is defined for  for 
32-bit
1260  * compiles and __amd64 is defined for 64-bit compiles.  Unlike 
SPARC,
1261  * they are defined exclusive of one another (see PSARC 2004/619).
1262  */
1263 if (dtp->dt_conf.dtc_ctfmodel == CTF_MODEL_LP64) {
1264 if (dt_cpp_add_arg(dtp, "-D__amd64") == NULL)
1265 return (set_open_errno(dtp, errp, EDT_NOMEM));
1266 } else {
1267 if (dt_cpp_add_arg(dtp, "-D__i386") == NULL)
1268 return (set_open_errno(dtp, errp, EDT_NOMEM));
1269 }
1270 #endif
1271 #else
1272 #if defined(__amd64__) || defined(__i386__)
1273 if (dtp->dt_conf.dtc_ctfmodel == CTF_MODEL_LP64) {
1274 if (dt_cpp_add_arg(dtp, "-m64") == NULL)
1275 return (set_open_errno(dtp, errp, EDT_NOMEM));
1276 } else {
1277 if (dt_cpp_add_arg(dtp, "-m32") == NULL)
1278 return (set_open_errno(dtp, errp, EDT_NOMEM));
1279 }
1280 #endif
1281 #endif

As for why the original issue occurred on my VM (which was the powerpc:powerpc 
case), I’m not sure yet. I’m working on figuring that out.

Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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]

> 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 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 obj.powerpc?
>>> I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
>>> tinderbox".
>> 
>> Is it possible that the file is left over from a previous build (of amd64?)
>> 
>> Does your log show it being built?
>> 
>> 
>>> dtrace -C -x nolibs -G -o usdt.o -s 
>>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
>>>  tst.usdt.o
>>> dtrace: failed to link script 
>>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>>  incorrect ELF machine type for object file: tst.usdt.o
>>> *** Error code 1
>>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>>> $ file 
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
>>> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
> 
> Still running into issues on ref11-amd64:
> 
> cc1: error: unrecognized command line option "-m64"
> dtrace: failed to compile script 
> /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>  Preprocessor failed to process input program
> --- usdt.h ---
> *** [usdt.h] Error code 1
> 
> Let’s see what happens if I use make buildenv

…

Deleting the lines that pass -m32/-m64 gets me back to the same point I was at 
before:

dtrace: failed to link script 
/scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
 incorrect ELF machine type for object file: tst.usdt.o
--- usdt.o ---
*** [usdt.o] Error code 1

I’ll need to check .PATH, but I think it’s picking up the host copy by accident:

$ find ../obj/ -name  tst.usdt.o | xargs file
../obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
   ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped
../obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
   ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not 
stripped
../obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
 ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not 
stripped
../obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
   ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), not 
stripped
../obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
 ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not 
stripped
../obj/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:  
 ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not 
stripped
../obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
 ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not 
stripped
../obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
 ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not 
stripped
../obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
 ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), 
not stripped
../obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
 ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not stripped
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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]

> 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 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 obj.powerpc?
I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
 tinderbox".
>>> 
>>> Is it possible that the file is left over from a previous build (of amd64?)
>>> 
>>> Does your log show it being built?
>>> 
>>> 
 dtrace -C -x nolibs -G -o usdt.o -s 
 /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
  tst.usdt.o
 dtrace: failed to link script 
 /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
  incorrect ELF machine type for object file: tst.usdt.o
 *** Error code 1
 $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
 $ file 
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: 
 ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
>> 
>> Still running into issues on ref11-amd64:
>> 
>> cc1: error: unrecognized command line option "-m64"
>> dtrace: failed to compile script 
>> /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>  Preprocessor failed to process input program
>> --- usdt.h ---
>> *** [usdt.h] Error code 1
>> 
>> Let’s see what happens if I use make buildenv
> 
> …
> 
> Deleting the lines that pass -m32/-m64 gets me back to the same point I was 
> at before:
> 
> dtrace: failed to link script 
> /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>  incorrect ELF machine type for object file: tst.usdt.o
> --- usdt.o ---
> *** [usdt.o] Error code 1
> 
> I’ll need to check .PATH, but I think it’s picking up the host copy by 
> accident:
> 
> $ find ../obj/ -name  tst.usdt.o | xargs file
> ../obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not 
> stripped
> ../obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not 
> stripped
> ../obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>  ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not 
> stripped
> ../obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), 
> not stripped
> ../obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>  ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not 
> stripped
> ../obj/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), 
> not stripped
> ../obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>  ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not 
> stripped
> ../obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>  ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not 
> stripped
> ../obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>  ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 
> (FreeBSD), not stripped
> ../obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>  ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not 
> stripped

And here’s the real issue — .PATH is completely broken when TARGET/TARGET_ARCH 
are specified as explicit values:

$ env MAKEOBJDIRPREFIX=/scratch/tmp/ngie/obj/ make buildenv TARGET=powerpc 
TARGET_ARCH=powerpc
Entering world for powerpc:powerpc
$ cd cddl/usr.sbin/dtrace/tests/common/json
$ make -V.OBJDIR
/scratch/tmp/ngie/obj//powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json
$ make -VMAKEOBJDIRPREFIX
/scratch/tmp/ngie/obj//powerpc.powerpc
$ make depend
(cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
_RECURSING_PROGS=  PROG=tst.usdt.exe  depend)
$ make all
(cd 

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

[Bryan Drewery]

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 
> importantly, why is the object not being put in obj.powerpc?
>   I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
> tinderbox".
> Thanks!
> -NGie
> 

Have you modified any of your local toolchain handling, or skipped
CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
there to be a lot more reports if there was a problem with buildworld
cross compiling.

> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
> …
> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
> _RECURSING_PROGS=  PROG=tst.usdt.exe )
> cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json 
> -std=gnu99 -fstack-protector-strong-c 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>  -o tst.usdt.o
> dtrace -C -x nolibs -G -o usdt.o -s 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
> tst.usdt.o
> dtrace: failed to link script 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: 
> incorrect ELF machine type for object file: tst.usdt.o
> *** Error code 1
> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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]

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 obj.powerpc?
I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
tinderbox".
Thanks!
-NGie

% make buildworld TARGET=powerpc TARGET_ARCH=powerpc
…
===> cddl/usr.sbin/dtrace/tests/common/json (all)
(cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS=  
PROG=tst.usdt.exe )
cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
-I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json 
-std=gnu99 -fstack-protector-strong-c 
/usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
 -o tst.usdt.o
dtrace -C -x nolibs -G -o usdt.o -s 
/usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
tst.usdt.o
dtrace: failed to link script 
/usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: 
incorrect ELF machine type for object file: tst.usdt.o
*** Error code 1
$ find /usr/obj/usr/src/svn/ -name tst.usdt.o
/usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
$ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
/usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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

[Bryan Drewery]

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 I specify powerpc/powerpc — and more 
>> importantly, why is the object not being put in obj.powerpc?
>>  I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
>> tinderbox".
>> Thanks!
>> -NGie
>>
> 
> Have you modified any of your local toolchain handling, or skipped
> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
> there to be a lot more reports if there was a problem with buildworld
> cross compiling.
> 
>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>> …
>> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
>> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
>> _RECURSING_PROGS=  PROG=tst.usdt.exe )
>> cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>>  -std=gnu99 -fstack-protector-strong-c 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>>  -o tst.usdt.o
>> dtrace -C -x nolibs -G -o usdt.o -s 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
>> tst.usdt.o
>> dtrace: failed to link script 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>  incorrect ELF machine type for object file: tst.usdt.o
>> *** Error code 1
>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
>> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
>>

I ran a buildworld with TARGET=powerpc just a few days ago and it seemed
to be fine with PROGS.  Here's a test object built via PROGS:

~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o
/usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
~/git/freebsd # file
/usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
/usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o:
ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD),
not stripped
-rw-r--r--  1 root  wheel  21136 Oct 23 17:08
/usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o

I see nothing special with the DTRACE_TESTS to change any of this.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Mark Johnston]

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 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 obj.powerpc?
>   I ran into the same issue on ref11-amd64.freebsd.org when I ran 
>  “make tinderbox".
>  Thanks!
>  -NGie
> 
> >>>
> >>> Have you modified any of your local toolchain handling, or skipped
> >>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
> >>> there to be a lot more reports if there was a problem with buildworld
> >>> cross compiling.
> >>>
>  % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>  …
>  ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>  (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
>  DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
>  /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
>  _RECURSING_PROGS=  PROG=tst.usdt.exe )
>  cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
>  -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>   -std=gnu99 -fstack-protector-strong-c 
>  /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>   -o tst.usdt.o
>  dtrace -C -x nolibs -G -o usdt.o -s 
>  /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
>   tst.usdt.o
>  dtrace: failed to link script 
>  /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>   incorrect ELF machine type for object file: tst.usdt.o
>  *** Error code 1
> 
> The problem looks specific to compiling of .d files using dtrace(1). It
> must not have cross-compile support.
> 
> The manpage does say: "The D compiler produces programs using the native
> data model of the operating system kernel.".
> 
> So these will need to be disabled for non-native builds.
> 
> I don't know if it would be possible to build a cross-compile version of
> dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work.

In the snippet above, tst.usdt.o is generated by cc, not dtrace(1).
dtrace is complaining that the input file doesn't have the expected
machine type, which seems valid given the file(1) output below.

> 
>  $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>  /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>  $ file 
>  /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>  /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: 
>  ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
> 
> >>
> >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed
> >> to be fine with PROGS.  Here's a test object built via PROGS:
> >>
> >> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o
> >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> >> ~/git/freebsd # file
> >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o:
> >> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD),
> >> not stripped
> >> -rw-r--r--  1 root  wheel  21136 Oct 23 17:08
> >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> >>
> >> I see nothing special with the DTRACE_TESTS to change any of this.
> > 
> > I could see there being a possible issue with my host VM, but I
> > haven't modified my environment in ref11-amd64.freebsd.org at all.
> > 
> > Could you please try reproing it there with your user?
> > 
> > Thanks,
> > -NGie
> > 
> 
> 
> -- 
> Regards,
> Bryan Drewery
> 


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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

[Bryan Drewery]

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 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 importantly, why is the object not being put 
>> in obj.powerpc?
>>  I ran into the same issue on ref11-amd64.freebsd.org when I ran 
>> “make tinderbox".
>> Thanks!
>> -NGie
>>
>
> Have you modified any of your local toolchain handling, or skipped
> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
> there to be a lot more reports if there was a problem with buildworld
> cross compiling.
>
>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>> …
>> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
>> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
>> _RECURSING_PROGS=  PROG=tst.usdt.exe )
>> cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>>  -std=gnu99 -fstack-protector-strong-c 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>>  -o tst.usdt.o
>> dtrace -C -x nolibs -G -o usdt.o -s 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
>>  tst.usdt.o
>> dtrace: failed to link script 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>  incorrect ELF machine type for object file: tst.usdt.o
>> *** Error code 1
>>
>> The problem looks specific to compiling of .d files using dtrace(1). It
>> must not have cross-compile support.
>>
>> The manpage does say: "The D compiler produces programs using the native
>> data model of the operating system kernel.".
>>
>> So these will need to be disabled for non-native builds.
>>
>> I don't know if it would be possible to build a cross-compile version of
>> dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work.
> 
> In the snippet above, tst.usdt.o is generated by cc, not dtrace(1).
> dtrace is complaining that the input file doesn't have the expected
> machine type, which seems valid given the file(1) output below.
> 

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 {} +
/scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
  ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
  ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
  ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1
(FreeBSD), not stripped
/scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
(FreeBSD), not stripped

[sorry for bad mail client]



>>
>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> $ file 
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> 

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

[Simon J. Gerraty]

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 object not being put in obj.powerpc?
>   I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
> tinderbox".

Is it possible that the file is left over from a previous build (of amd64?)

Does your log show it being built?


> dtrace -C -x nolibs -G -o usdt.o -s 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
> tst.usdt.o
> dtrace: failed to link script 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: 
> incorrect ELF machine type for object file: tst.usdt.o
> *** Error code 1
> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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]

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 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 obj.powerpc?
>>>  I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
>>> tinderbox".
>>> Thanks!
>>> -NGie
>>>
>>
>> Have you modified any of your local toolchain handling, or skipped
>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
>> there to be a lot more reports if there was a problem with buildworld
>> cross compiling.
>>
>>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>>> …
>>> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
>>> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
>>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
>>> _RECURSING_PROGS=  PROG=tst.usdt.exe )
>>> cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
>>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>>>  -std=gnu99 -fstack-protector-strong-c 
>>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>>>  -o tst.usdt.o
>>> dtrace -C -x nolibs -G -o usdt.o -s 
>>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
>>>  tst.usdt.o
>>> dtrace: failed to link script 
>>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>>  incorrect ELF machine type for object file: tst.usdt.o
>>> *** Error code 1
>>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>>> $ file 
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
>>> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
>>>
>
> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed
> to be fine with PROGS.  Here's a test object built via PROGS:
>
> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o
> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> ~/git/freebsd # file
> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o:
> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD),
> not stripped
> -rw-r--r--  1 root  wheel  21136 Oct 23 17:08
> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
>
> I see nothing special with the DTRACE_TESTS to change any of this.

I could see there being a possible issue with my host VM, but I
haven't modified my environment in ref11-amd64.freebsd.org at all.

Could you please try reproing it there with your user?

Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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

[Bryan Drewery]

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 -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 obj.powerpc?
  I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
 tinderbox".
 Thanks!
 -NGie

>>>
>>> Have you modified any of your local toolchain handling, or skipped
>>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
>>> there to be a lot more reports if there was a problem with buildworld
>>> cross compiling.
>>>
 % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
 …
 ===> cddl/usr.sbin/dtrace/tests/common/json (all)
 (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
 DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
 /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
 _RECURSING_PROGS=  PROG=tst.usdt.exe )
 cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
 -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
  -std=gnu99 -fstack-protector-strong-c 
 /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
  -o tst.usdt.o
 dtrace -C -x nolibs -G -o usdt.o -s 
 /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
  tst.usdt.o
 dtrace: failed to link script 
 /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
  incorrect ELF machine type for object file: tst.usdt.o
 *** Error code 1

The problem looks specific to compiling of .d files using dtrace(1). It
must not have cross-compile support.

The manpage does say: "The D compiler produces programs using the native
data model of the operating system kernel.".

So these will need to be disabled for non-native builds.

I don't know if it would be possible to build a cross-compile version of
dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work.

 $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
 $ file 
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: 
 ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

>>
>> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed
>> to be fine with PROGS.  Here's a test object built via PROGS:
>>
>> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o
>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
>> ~/git/freebsd # file
>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o:
>> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD),
>> not stripped
>> -rw-r--r--  1 root  wheel  21136 Oct 23 17:08
>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
>>
>> I see nothing special with the DTRACE_TESTS to change any of this.
> 
> I could see there being a possible issue with my host VM, but I
> haven't modified my environment in ref11-amd64.freebsd.org at all.
> 
> Could you please try reproing it there with your user?
> 
> Thanks,
> -NGie
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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]

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 {} +
> /scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>   ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>   ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>   ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1
> (FreeBSD), not stripped
> /scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
> (FreeBSD), not stripped
>
> [sorry for bad mail client]

Weird. Ok, I'll do some more digging into this.
Thanks for the input!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Matt Smith]

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, but I *have* to go
to bed now.


It's done.



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?


--
Matt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Kurt Jaeger]

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 ?

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Matt Smith]

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 you suggest a patch ?



Unfortunately not I'm afraid. I'm not familiar enough with the newer 
intricacies of the ports system these days. I'm just a little OCD about 
only having ports installed which are needed for runtime and I usually 
run pkg_clean after every port update run to remove unneeded things. GCC 
just popped out as being unneeded to run mediatomb.


--
Matt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Don Lewis]

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 patch. :)
>>>
>>> Thanks, helps to build it. Still fails on 9.3a, but I *have* to go
>>> to bed now.
>>
>>It's done.
>>
> 
> 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?

If the executable(s) link to any of the shared libraries bundled with
the gcc port, then gcc needs to be a run time dependency.  If you point
ldd at one of the executables, what does it say?


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Matt Smith]

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 actual patch. :)

Thanks, helps to build it. Still fails on 9.3a, but I *have* to go
to bed now.


It's done.



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?


If the executable(s) link to any of the shared libraries bundled with
the gcc port, then gcc needs to be a run time dependency.  If you point
ldd at one of the executables, what does it say?



Good point. I remember now that some things like against libgcc provided with 
the GCC package. If this is the case then I apologise for the noise and feel 
free to ignore me! Unfortunately I don't currently have access to the box where 
I compiled it using GCC last night using the updated port. I only have access 
to another box where it was compiled using clang (on -STABLE). This shows the 
below. So I can see that it is linked against libgcc, although in this case the 
base system version.

$ ldd `which mediatomb`
/usr/local/bin/mediatomb:
   libthr.so.3 => /lib/libthr.so.3 (0x80094b000)
   librt.so.1 => /usr/lib/librt.so.1 (0x800b6f000)
   libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x800d75000)
   libmagic.so.4 => /usr/lib/libmagic.so.4 (0x801029000)
   libz.so.6 => /lib/libz.so.6 (0x801248000)
   libavformat.so.56 => /usr/local/lib/libavformat.so.56 (0x80145e000)
   libavutil.so.54 => /usr/local/lib/libavutil.so.54 (0x801821000)
   libffmpegthumbnailer.so.4 => /usr/local/lib/libffmpegthumbnailer.so.4 
(0x801a86000)
   libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x801c9b000)
   libc++.so.1 => /usr/lib/libc++.so.1 (0x801ec1000)
   libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80218)
   libm.so.5 => /lib/libm.so.5 (0x80239c000)
   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8025c5000)
   libc.so.7 => /lib/libc.so.7 (0x8027d3000)
   libavcodec.so.56 => /usr/local/lib/libavcodec.so.56 (0x802c0)
   libssl.so.8 => /usr/local/lib/libssl.so.8 (0x803f0e000)
   libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x80420)
   libbz2.so.4 => /usr/lib/libbz2.so.4 (0x804651000)
   libswscale.so.3 => /usr/local/lib/libswscale.so.3 (0x804863000)
   libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804af5000)
   libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x804d27000)
   libswresample.so.1 => /usr/local/lib/libswresample.so.1 (0x804f8)
   libx264.so.144 => /usr/local/lib/libx264.so.144 (0x80519b000)
   libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x8054fd000)
   libfdk-aac.so.1 => /usr/local/lib/libfdk-aac.so.1 (0x805776000)
   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x805a43000)

--
Matt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Don Lewis]

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:
> > >
> > > 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.

It's done.

>>>
>>> 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?
>>
>>If the executable(s) link to any of the shared libraries bundled with
>>the gcc port, then gcc needs to be a run time dependency.  If you
>>point ldd at one of the executables, what does it say?
>>
> 
> Good point. I remember now that some things like against libgcc
> provided with the GCC package. If this is the case then I apologise
> for the noise and feel free to ignore me! Unfortunately I don't
> currently have access to the box where I compiled it using GCC last
> night using the updated port. I only have access to another box where
> it was compiled using clang (on -STABLE). This shows the below. So I
> can see that it is linked against libgcc, although in this case the
> base system version.
> 
> $ ldd `which mediatomb`
> /usr/local/bin/mediatomb:
> libthr.so.3 => /lib/libthr.so.3 (0x80094b000)
> librt.so.1 => /usr/lib/librt.so.1 (0x800b6f000)
> libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x800d75000)
> libmagic.so.4 => /usr/lib/libmagic.so.4 (0x801029000)
> libz.so.6 => /lib/libz.so.6 (0x801248000)
> libavformat.so.56 => /usr/local/lib/libavformat.so.56 (0x80145e000)
> libavutil.so.54 => /usr/local/lib/libavutil.so.54 (0x801821000) 
> libffmpegthumbnailer.so.4 => /usr/local/lib/libffmpegthumbnailer.so.4 
> (0x801a86000) 
> libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x801c9b000) 
> libc++.so.1 => /usr/lib/libc++.so.1 (0x801ec1000)

Since this is a c++ thing, you'll probably find that the version
compiled with gcc from ports is linked to libstdc++ bundled with the
ports version of gcc.

BTW, if it gets linked to both libstdc++ and libc++, it will blow up
at runtime.  If this ports links to other libraries that contain c++
code built with clang, then USES=compiler:gcc-c++11-lib won't work
because the two c++ implementations don't play well together.

> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80218)
> libm.so.5 => /lib/libm.so.5 (0x80239c000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8025c5000)
> libc.so.7 => /lib/libc.so.7 (0x8027d3000)
> libavcodec.so.56 => /usr/local/lib/libavcodec.so.56 (0x802c0)
> libssl.so.8 => /usr/local/lib/libssl.so.8 (0x803f0e000)
> libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x80420)
> libbz2.so.4 => /usr/lib/libbz2.so.4 (0x804651000)
> libswscale.so.3 => /usr/local/lib/libswscale.so.3 (0x804863000)
> libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804af5000)
> libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x804d27000)
> libswresample.so.1 => /usr/local/lib/libswresample.so.1 (0x804f8)
> libx264.so.144 => /usr/local/lib/libx264.so.144 (0x80519b000)
> libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x8054fd000)
> libfdk-aac.so.1 => /usr/local/lib/libfdk-aac.so.1 (0x805776000)
> liblzma.so.5 => /usr/lib/liblzma.so.5 (0x805a43000)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Kurt Jaeger]

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.

It's done.

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Kevin Oberman]

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  -I..
-I/usr/local/include-I/usr/local/include
-I/usr/local/include/taglib  -I/usr/local/include
-D_THREAD_SAFE  -I/usr/local/include  -I/usr/local/include   -O2
-pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing
-DLIBICONV_PLUG -MT libmediatomb_a-timer.o -MD -MP -MF
.deps/libmediatomb_a-timer.Tpo -c -o libmediatomb_a-timer.o `test -f
'../src/timer.cc' || echo './'`../src/timer.cc
../src/timer.cc:40:1: error: explicit specialization of 'mutex' after
  instantiation
SINGLETON_MUTEX(Timer, true);
^
../src/singleton.h:112:89: note: expanded from macro 'SINGLETON_MUTEX'
  ...recursive) template <> zmm::Ref Singleton::mutex =
zmm::Re...
  ^
../src/timer.h:82:18: note: implicit instantiation first required here
AUTOLOCK(mutex);
 ^
../src/sync.h:40:66: note: expanded from macro 'AUTOLOCK'
#define AUTOLOCK(mutex) zmm::Ref mutex_autolock = mutex->...
 ^
1 error generated.

The macro in question is:
#define SINGLETON_MUTEX(klass, recursive) template <> zmm::Ref
Singleton::mutex = zmm::Ref(new Mutex(recursive))
//template  zmm::Ref Singleton::mutex =
zmm::Ref(new Mutex());
template  zmm::Ref Singleton::instance = nil;
template  bool Singleton::singletonActive = true;

Is this a problem with the code or the compiler? If it is the code, any
suggestions on fixing it? I have no clue about C++, but I'd really like to
get this working on HEAD.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Dimitry Andric]

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 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. :)

-Dimitry


patch-timer.cc
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Dimitry Andric]

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:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436

but it did not get applied, because it apparently caused a build failure
on 8.4 (for which the log is not available anymore, so no idea what the
problem was).

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Kurt Jaeger]

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.

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Kevin Oberman]

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. :)
>
> Thanks, helps to build it. Still fails on 9.3a, but I *have* to go
> to bed now.
>
> --
> p...@opsec.eu+49 171 3101372 5 years to
> go !
>

Hmm. Looks like something is going wrong with Mk/Uses/iconv.  The failing
test for iconv builds without -liconv.

Now it's time for me to get some sleep. Here is the relevant section of the
log:
configure:8520: checking iconv.h usability
configure:8537: cc -c -O2 -pipe -fstack-protector -fno-strict-aliasing
-I/usr/local/include conftest.c >&5
configure:8544: $? = 0
configure:8558: result: yes
configure:8562: checking iconv.h presence
configure:8577: cpp -I/usr/local/include conftest.c
configure:8584: $? = 0
configure:8598: result: yes
configure:8631: checking for iconv.h
configure:8638: result: yes
configure:9290: checking for iconv
configure:9346: cc -o conftest -O2 -pipe -fstack-protector
-fno-strict-aliasing -I/usr/local/include  -lpthread -fstack-protector
conftest.c  >&5
/tmp/ccLEMR46.o: In function `main':
conftest.c:(.text+0x7): undefined reference to `iconv'
configure:9353: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "MediaTomb"
| #define PACKAGE_TARNAME "mediatomb"
| #define PACKAGE_VERSION "0.12.1"
| #define PACKAGE_STRING "MediaTomb 0.12.1"
| #define PACKAGE_BUGREPORT "j...@mediatomb.cc"
#define PACKAGE "mediatomb"
| #define VERSION "0.12.1"
| #define EXTEND_PROTOCOLINFO 1
| #define UPNP_VERSION_STRING "0.12.1"
| #define UPNP_VERSION_MAJOR 0
| #define UPNP_VERSION_MINOR 4
| #define UPNP_VERSION_PATCH 1
| #define HAVE_DIRENT_H 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_WAIT_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE__BOOL 1
| #define HAVE_STDBOOL_H 1
| #define TIME_WITH_SYS_TIME 1
| #define HAVE_TIME_H 1
| #define HAVE_SYSLOG_H 1
| #define HAVE_STDDEF_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_ARPA_INET_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_NETDB_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_WAIT_H 1
| #define HAVE_LANGINFO_H 1
| #define HAVE_LOCALE_H 1
| #define HAVE_SYS_UTSNAME_H 1
| #define HAVE_SCHED_H 1
| #define HAVE_CTYPE_H 1
| #define HAVE_SCHED_GETPARAM 1
| #define HAVE_SCHED_SETPARAM 1
| #define HAVE_SCHED_GET_PRIORITY_MIN 1
| #define HAVE_SCHED_GET_PRIORITY_MAX 1
| #define HAVE_MKDIR 1
| #define HAVE_GETOPT_H 1
| #define HAVE_GETOPT_LONG 1
| #define HAVE_MKFIFO 1
| #define EXTERNAL_TRANSCODING 1
| /* end confdefs.h.  */
| /* Define iconv to an innocuous variant, in case  declares
iconv.
|For example, HP-UX 11i  declares gettimeofday.  */
| #define iconv innocuous_iconv
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char iconv (); below.
| Prefer  to  if __STDC__ is defined, since
|  exists even on freestanding compilers.  */
|
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
|
| #undef iconv
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char iconv ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS.  Some functions are actually named
| something starting with __ and the normal name is an alias.  */
| #if defined __stub_iconv || defined __stub___iconv
| choke me
| #endif
|
| int
| main ()
| {
| return iconv ();
|   ;
|   return 0;
| }
configure:9373: result: no

--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Need help reducing compilation warnings in CURRENT

[Craig Rodrigues]

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 might be even one real bug in SU code uncovered, but I am not
 sure yet.

 Please review at https://reviews.freebsd.org/D2665 .
 I do not have an intention of splitting this into individual changes.


Thanks for committing these fixes.
Jenkins detected this as fixing 42 warnings:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/34/warnings17Result/

Every little bit helps!

--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help reducing compilation warnings in CURRENT

[Garrett Cooper]

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
 knowledgable, to correct some 'assigned but not used variable' warnings.
 There might be even one real bug in SU code uncovered, but I am not
 sure yet.
 
 Please review at https://reviews.freebsd.org/D2665 .
 I do not have an intention of splitting this into individual changes.
 
 
 Thanks for committing these fixes.
 Jenkins detected this as fixing 42 warnings:
 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/34/warnings17Result/
 
 Every little bit helps!

The -Wstrict-aliasing warnings are particularly useful, considering clang still 
doesn’t support this detection…
Thanks :)!
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Need help reducing compilation warnings in CURRENT

[NGie Cooper]

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 slammed by multiple downstream
projects, so if we can contribute back fixes or pull in upstream fixes
as cherrypicks through the vendor tree, then that would reduce our
diff and make sure that upstream projects benefit from our changes.

The only time we should really be modifying and not giving back is
when we have FreeBSD-specific modifications that don't make sense in
upstream projects. Those should be rare occurrences though...

Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help reducing compilation warnings in CURRENT

[Dimitry Andric]

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 upstream that would be great.
 However, we shouldn't let that block us from comitting fixes to FreeBSD.

Yes, that should block us in most cases, since it will make future
merges more difficult.

We should only fix these types of warnings locally, if:
1) The contrib project's upstream is dead, unresponsive, or hostile.
2) You are sure that you don't introduce new bugs by modifying stuff.
   (You definitely don't want to repeat e.g. Debian's OpenSSL fiasco.)
3) You are sure that the warning exposes a real bug, that cannot be
   worked around in some other way.
4) You are sure that you want to take the maintenance burden of future
   merges.


 The advantage of having code in the FreeBSD repo is that we can
 change it if we need to, even if the fix isn't yet in the upstream sources.
 Contrib code is not made out of stone that can't be modified!

Certainly not, but unless you have very good reasons to modify upstream
code locally, you should not bother.  Better spend your energy to file
fixes upstream, and let *them* verify that they are correct.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Need help reducing compilation warnings in CURRENT

[Craig Rodrigues]

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. Hence, any fix might
 want to probably be submitted to upstream first.



Sure, if we can push fixes upstream that would be great.
However, we shouldn't let that block us from comitting fixes to FreeBSD.
The advantage of having code in the FreeBSD repo is that we can
change it if we need to, even if the fix isn't yet in the upstream sources.
Contrib code is not made out of stone that can't be modified!

--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help reducing compilation warnings in CURRENT

[Baptiste Daroussin]

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 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.
 
 
 
 Sure, if we can push fixes upstream that would be great.
 However, we shouldn't let that block us from comitting fixes to FreeBSD.
 The advantage of having code in the FreeBSD repo is that we can
 change it if we need to, even if the fix isn't yet in the upstream sources.
 Contrib code is not made out of stone that can't be modified!
 

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!!

Best regards,
Bapt


pgp0BlQSYtTQV.pgp
Description: PGP signature

Re: Need help reducing compilation warnings in CURRENT

[Craig Rodrigues]

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: https://wiki.freebsd.org/CodeReview
for instructions on how you can send patches to our code review tool.

--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Need help reducing compilation warnings in CURRENT

[Craig Rodrigues]

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 patches to clean up the code?

Cleaning up compiler warnings is always boring work,
but it is good to clean up the code over time.

--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help reducing compilation warnings in CURRENT

[Marcelo Araujo]

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:

 https://jenkins.freebsd.org/job/FreeBSD_HEAD/warnings7

 Can anyone help improve the code by periodically looking
 at this table and submitting patches to clean up the code?

 Cleaning up compiler warnings is always boring work,
 but it is good to clean up the code over time.

 --
 Craig
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org




-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org http://www.freebsd.org/   \/  \ ^
Power To Server. .\. /_)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help reducing compilation warnings in CURRENT

[Johannes Jost Meixner]

-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 I'm missing something obvious here please ;-)

- -J

On 05/28/2015 09:30, 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 improve the code by periodically looking at this
 table and submitting patches to clean up the code?
 
 Cleaning up compiler warnings is always boring work, but it is good
 to clean up the code over time.
 
 -- Craig ___ 
 freebsd-test...@freebsd.org mailing list 
 https://lists.freebsd.org/mailman/listinfo/freebsd-testing To
 unsubscribe, send any mail to
 freebsd-testing-unsubscr...@freebsd.org
 

- -- 
Johannes Meixner| FreeBSD Committer
x...@freebsd.org | http://people.freebsd.org/~xmj
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVZwxUAAoJEPyeKTcbGw0Lh7wH/2G4ZvwLCvDisEp4pJthlaQZ
KNSQWTGILkhGWK2NkDqe5zsFl4SbTGIH83JgHZVoArChoa5vxQ6FXgdyYNl6ep2i
kGveOpE/U/Z2OT89Jirh4dllxkSHYNd76vbUWJrG70Cgss+5JNuYxO/1hO6Vg0xj
qnq1sSggjQzlMG5tgA3vobPz73p17eUdsWhlVgER18OJ3I7ZKEB+spYiu8B3N3HF
E0CsoOy9NaLmVD0i7oZpaH8Rev8CJzJ9hBTDex6o/pIR735/3SZu+NtOGfU4Viqx
DFfE1qIQUO1uXDFb9UK7s0SanTzJnzi9amWoiB1DSGKhgTbAF5XeTqRso6QyVxw=
=FziJ
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help reducing compilation warnings in CURRENT

[Muhammad Moinur Rahman]

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 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 I'm missing something obvious here please ;-)

 - -J

 On 05/28/2015 09:30, 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 improve the code by periodically looking at this
  table and submitting patches to clean up the code?
 
  Cleaning up compiler warnings is always boring work, but it is good
  to clean up the code over time.
 
  -- Craig ___
  freebsd-test...@freebsd.org mailing list
  https://lists.freebsd.org/mailman/listinfo/freebsd-testing To
  unsubscribe, send any mail to
  freebsd-testing-unsubscr...@freebsd.org
 

 - --
 Johannes Meixner| FreeBSD Committer
 x...@freebsd.org | http://people.freebsd.org/~xmj
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVZwxUAAoJEPyeKTcbGw0Lh7wH/2G4ZvwLCvDisEp4pJthlaQZ
 KNSQWTGILkhGWK2NkDqe5zsFl4SbTGIH83JgHZVoArChoa5vxQ6FXgdyYNl6ep2i
 kGveOpE/U/Z2OT89Jirh4dllxkSHYNd76vbUWJrG70Cgss+5JNuYxO/1hO6Vg0xj
 qnq1sSggjQzlMG5tgA3vobPz73p17eUdsWhlVgER18OJ3I7ZKEB+spYiu8B3N3HF
 E0CsoOy9NaLmVD0i7oZpaH8Rev8CJzJ9hBTDex6o/pIR735/3SZu+NtOGfU4Viqx
 DFfE1qIQUO1uXDFb9UK7s0SanTzJnzi9amWoiB1DSGKhgTbAF5XeTqRso6QyVxw=
 =FziJ
 -END PGP SIGNATURE-
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help reducing compilation warnings in CURRENT

[Marcelo Araujo]

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 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 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 I'm missing something obvious here please ;-)
 
  - -J
 
  On 05/28/2015 09:30, 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 improve the code by periodically looking at this
   table and submitting patches to clean up the code?
  
   Cleaning up compiler warnings is always boring work, but it is good
   to clean up the code over time.
  
   -- Craig ___
   freebsd-test...@freebsd.org mailing list
   https://lists.freebsd.org/mailman/listinfo/freebsd-testing To
   unsubscribe, send any mail to
   freebsd-testing-unsubscr...@freebsd.org
  
 
  - --
  Johannes Meixner| FreeBSD Committer
  x...@freebsd.org | http://people.freebsd.org/~xmj
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v2
 
  iQEcBAEBCAAGBQJVZwxUAAoJEPyeKTcbGw0Lh7wH/2G4ZvwLCvDisEp4pJthlaQZ
  KNSQWTGILkhGWK2NkDqe5zsFl4SbTGIH83JgHZVoArChoa5vxQ6FXgdyYNl6ep2i
  kGveOpE/U/Z2OT89Jirh4dllxkSHYNd76vbUWJrG70Cgss+5JNuYxO/1hO6Vg0xj
  qnq1sSggjQzlMG5tgA3vobPz73p17eUdsWhlVgER18OJ3I7ZKEB+spYiu8B3N3HF
  E0CsoOy9NaLmVD0i7oZpaH8Rev8CJzJ9hBTDex6o/pIR735/3SZu+NtOGfU4Viqx
  DFfE1qIQUO1uXDFb9UK7s0SanTzJnzi9amWoiB1DSGKhgTbAF5XeTqRso6QyVxw=
  =FziJ
  -END PGP SIGNATURE-
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org




-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org http://www.freebsd.org/   \/  \ ^
Power To Server. .\. /_)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help reducing compilation warnings in CURRENT

[Konstantin Belousov]

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 improve the code by periodically looking
 at this table and submitting patches to clean up the code?
 
 Cleaning up compiler warnings is always boring work,
 but it is good to clean up the code over time.

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 might be even one real bug in SU code uncovered, but I am not
sure yet.

Please review at https://reviews.freebsd.org/D2665 .
I do not have an intention of splitting this into individual changes.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Craig Rodrigues]

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 thing?  We can try it.

--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Benjamin Kaduk]

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 warnings nowhere close to all of
them (to avoid breaking peoples' builds as new warnings are introduced),
and a larger set would be better.  (Things like -Wmaybe-uninitialized have
too many false positives to be a desirable -Werror target, though.)

-Ben
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Eitan Adler]

On 18 April 2015 at 11:12, Craig Rodrigues rodr...@freebsd.org wrote:
 Hi,

 After the latest commits by members of freebsd-toolchain@ ,
 I have managed to compile latest CURRENT world and GENERIC
 kernel on amd64 with an gcc 4.9 external toolchain by doing:

pkg install devel/amd64-xtoolchain-gcc
cd /usr/src
sed -i  -e 's/boot2//' sys/boot/i386/Makefile
make buildworld CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=
make buildkernel CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=


 It was necessary 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 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 to
 patch the code to eliminate the warnings, please submit patches
 and commit them if you can.

Some time ago I tried to do something similar, but with gcc4.6 instead
of gcc4.9.

The vast majority of warnings (1548) are unused-but-set-variable and
it may be worthwhile to just silence this warning, at least at low
WARNS levels.  It has caught real errors but is quite noisy and can
cause quite a bit of churn.

inline (count 515) is generally pure noise, and I think we should
disable it.  It can be helpful to find certain types of performance
optimizations, but it should be opt-in.

strict-aliasing (154) are likely all real bugs of some form.  Very
few exist in contrib code, and it would be good to fix them.

Warning (111) seem to be a mix of warnings, but mostly in contrib code.

maybe-uninitialized (111) is often noisy, and in a spot check were
all false positives.

deprecated-declarations (22) is all in contrib code

Many of these are useful though and I've already fixed a few of the
bugs reported.

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?

-- 
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Adrian Chadd]

On 19 April 2015 at 02:10, Eitan Adler li...@eitanadler.com wrote:
 

 On 18 April 2015 at 11:12, Craig Rodrigues rodr...@freebsd.org wrote:
 Hi,

 After the latest commits by members of freebsd-toolchain@ ,
 I have managed to compile latest CURRENT world and GENERIC
 kernel on amd64 with an gcc 4.9 external toolchain by doing:

pkg install devel/amd64-xtoolchain-gcc
cd /usr/src
sed -i  -e 's/boot2//' sys/boot/i386/Makefile
make buildworld CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=
make buildkernel CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=


 It was necessary 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 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 to
 patch the code to eliminate the warnings, please submit patches
 and commit them if you can.

 Some time ago I tried to do something similar, but with gcc4.6 instead
 of gcc4.9.

 The vast majority of warnings (1548) are unused-but-set-variable and
 it may be worthwhile to just silence this warning, at least at low
 WARNS levels.  It has caught real errors but is quite noisy and can
 cause quite a bit of churn.

 inline (count 515) is generally pure noise, and I think we should
 disable it.  It can be helpful to find certain types of performance
 optimizations, but it should be opt-in.

 strict-aliasing (154) are likely all real bugs of some form.  Very
 few exist in contrib code, and it would be good to fix them.

 Warning (111) seem to be a mix of warnings, but mostly in contrib code.

 maybe-uninitialized (111) is often noisy, and in a spot check were
 all false positives.

 deprecated-declarations (22) is all in contrib code

 Many of these are useful though and I've already fixed a few of the
 bugs reported.

 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?

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.)



-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[Request for Help] Reducing gcc 4.9 compilation warnings

[Craig Rodrigues]

Hi,

After the latest commits by members of freebsd-toolchain@ ,
I have managed to compile latest CURRENT world and GENERIC
kernel on amd64 with an gcc 4.9 external toolchain by doing:

   pkg install devel/amd64-xtoolchain-gcc
   cd /usr/src
   sed -i  -e 's/boot2//' sys/boot/i386/Makefile
   make buildworld CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=
   make buildkernel CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=


It was necessary 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 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 to
patch the code to eliminate the warnings, please submit patches
and commit them if you can.

clang is still going to be the default compiler in the base system,
but it is nice to have FreeBSD compilable by multiple compilers.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[O. Hartmann]

Compiling emulators/virtualbox-ose on a freshly installed CURRENT
(FreeBSD 11.0-CURRENT #0 r273719: Mon Oct 27 07:59:12 CET 2014 amd64)
results in the below shown error.

I also tried to install the package on CURRENT via pkg install, but
this results in a 32-Bit VirtualBox only - which is inacceptable.

I have running emulators/virtualbox-ose on several other CURRENT
machines, but most of those boxes are grown, that means, they got
CURRENT months ago and are maintained as usual (buildworld/portmaster).
This box has been installed a couple of weeks ago and is successfully
rejecting 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 architectural compatibilities), I switched back to the FreeBSD
vanilla standard - but still the same. I can not imagine that the CPU
of that specific box could be the culprit:


dmesg output:

CPU: Intel(R) Core(TM)
i5-3470 CPU @ 3.20GHz (3192.82-MHz K8-class CPU) Origin=GenuineIntel
Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0x7fbae3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND
AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF
  Structured Extended Features=0x281FSGSBASE,SMEP,ERMS
  XSAVE Features=0x1XSAVEOPT
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 9107931136 (8686 MB)
avail memory = 8147902464 (7770 MB)

I have also problems compiling the port on a newly setup laptop (Intel
i5-4200M CPU/Haswell), CURRENT as of the same date as reported here.
The failure is the same. It seems, that on CURRENT installations as of
a certain date not far in the past, the port fails to recompile
successfully. 

The error is:


[...]

kBuild: Generating tstVMStructSize
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h
 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/bin/tstVMStructRC:
1: Syntax error: ( unexpected kmk: ***
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h]
Error 2 kmk: *** Deleting file
`/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h'
kmk: *** Waiting for unfinished jobs filesplitter: Out of 144
files: 144 rewritten, 0 unchanged.
(/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include)
kmk_builtin_append
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers
kmk: *** Exiting with status 2 *** Error code 2
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

SVN r273734 breaks i386 compilation

[Michael Butler]

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 -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c
/usr/src/bin/dd/args.c
/usr/src/bin/dd/args.c:192:43: error: format specifies type 'intmax_t'
(aka 'long long') but the argument has type 'int' [-Werror,-Wformat]
errx(1, bs must be between 1 and %jd, SSIZE_MAX);
  ~~~   ^
  %d


/usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from
macro 'SSIZE_MAX'
#define SSIZE_MAX   __SSIZE_MAX /* max value for an ssize_t */
^~~
/usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded
from macro '__SSIZE_MAX'
#define __SSIZE_MAX __INT_MAX
^
/usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded
from macro '__INT_MAX'
#define __INT_MAX   0x7fff  /* max value for an int */
^~
/usr/src/bin/dd/args.c:201:44: error: format specifies type 'intmax_t'
(aka 'long long') but the argument has type 'int' [-Werror,-Wformat]
errx(1, cbs must be between 1 and %jd, SSIZE_MAX);
   ~~~   ^
   %d


/usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from
macro 'SSIZE_MAX'
#define SSIZE_MAX   __SSIZE_MAX /* max value for an ssize_t */
^~~
/usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded
from macro '__SSIZE_MAX'
#define __SSIZE_MAX __INT_MAX
^
/usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded
from macro '__INT_MAX'
#define __INT_MAX   0x7fff  /* max value for an int */
^~
/usr/src/bin/dd/args.c:221:46: error: format specifies type 'uintmax_t'
(aka 'unsigned long long') but the argument has type 'unsigned int'
[-Werror,-Wformat]
errx(1, files must be between 1 and %ju, SIZE_MAX);
 ~~~   ^~~~
 %u
/usr/obj/usr/src/tmp/usr/include/x86/_stdint.h:180:18: note: expanded
from macro 'SIZE_MAX'
#define SIZE_MAXUINT32_MAX
^~
/usr/obj/usr/src/tmp/usr/include/x86/_stdint.h:82:20: note: expanded
from macro 'UINT32_MAX'
#define UINT32_MAX  0xU
^~~
/usr/src/bin/dd/args.c:241:45: error: format specifies type 'uintmax_t'
(aka 'unsigned long long') but the argument has type 'int'
[-Werror,-Wformat]
errx(1, ibs must be between 1 and %ju, SSIZE_MAX);
   ~~~   ^
   %d
/usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from
macro 'SSIZE_MAX'
#define SSIZE_MAX   __SSIZE_MAX /* max value for an ssize_t */
^~~
/usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded
from macro '__SSIZE_MAX'
#define __SSIZE_MAX __INT_MAX
^
/usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded
from macro '__INT_MAX'
#define __INT_MAX   0x7fff  /* max value for an int */
^~
/usr/src/bin/dd/args.c:259:45: error: format specifies type 'intmax_t'
(aka 'long long') but the argument has type 'int' [-Werror,-Wformat]
errx(1, obs must be between 1 and %jd, SSIZE_MAX);
   ~~~   ^
   %d
/usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from
macro 'SSIZE_MAX'
#define SSIZE_MAX   __SSIZE_MAX /* max value for an ssize_t */
^~~
/usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded
from macro '__SSIZE_MAX'
#define __SSIZE_MAX __INT_MAX
^
/usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded
from macro '__INT_MAX'
#define __INT_MAX   0x7fff  /* max value for an int */
^~
5 errors generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/src/bin/dd
*** Error code 1



signature.asc
Description: 

Re: SVN r273734 breaks i386 compilation

[Kurt Jaeger]

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
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[David Shao]

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);
printf(RX packets = %lx\n, rxr-rx_packets);

all cause
error: format specifies type 'unsigned long' but the argument has type
'u64' (aka 'unsigned long long') [-Werror,-Wformat]

In function ixl_stat_update48(struct i40e_hw *hw, u32 hireg, u32 loreg,
bool offset_loaded, u64 *offset, u64 *stat)


#if __FreeBSD__ = 10  __amd64__

causes
error:  '__amd64__' is not defined, evaluates to 0 [-Werror,-Wundef]
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Steven Hartland]

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/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);
   printf(RX packets = %lx\n, rxr-rx_packets);

all cause
error: format specifies type 'unsigned long' but the argument has type
'u64' (aka 'unsigned long long') [-Werror,-Wformat]

In function ixl_stat_update48(struct i40e_hw *hw, u32 hireg, u32 
loreg,

   bool offset_loaded, u64 *offset, u64 *stat)


#if __FreeBSD__ = 10  __amd64__

causes
error:  '__amd64__' is not defined, evaluates to 0 [-Werror,-Wundef]
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
freebsd-current-unsubscr...@freebsd.org




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Bjoern A. Zeeb]

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 least compile now.  To which extends some things work I have no idea.

/bz

— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[David Wolfskill]

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 follow-up commits that (if I didn?t screw up) should make 
 things at least compile now.  To which extends some things work I have no 
 idea.
 

Err  I think I'm seeing this (or a related) problem @r270799:

 Kernel build for CANARY started on Fri Aug 29 06:17:52 PDT 2014
..ll_subdir_ixlv ---
--- if_ixlv.o ---
clang -O2 -pipe  -DSMP -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE 
-nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include 
/common/S4/obj/usr/src/sys/CANARY/opt_global.h -I. -I@ -I@/contrib/altq 
-fno-common -g -I/common/S4/obj/usr/src/sys/CANARY  -mno-mmx -mno-sse 
-msoft-float -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx 
-Qunused-arguments -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  -mno-aes -mno-avx 
-Qunused-arguments -c /usr/src/sys/modules/ixlv/../../dev/ixl/if_ixlv.c
--- all_subdir_ixl ---
/usr/src/sys/modules/ixl/../../dev/ixl/i40e_osdep.c:66:1: error: conflicting 
types for 'i40e_allocate_dma'
i40e_allocate_dma(struct i40e_hw *hw, struct i40e_dma_mem *dma,
^
/usr/src/sys/modules/ixl/../../dev/ixl/i40e_alloc.h:54:23: note: previous 
declaration is here
enum i40e_status_code i40e_allocate_dma_mem(struct i40e_hw *hw,
  ^
/usr/src/sys/modules/ixl/../../dev/ixl/i40e_osdep.h:169:51: note: expanded from 
macro 'i40e_allocate_dma_mem'
#define i40e_allocate_dma_mem(h, m, unused, s, a) i40e_allocate_dma(h, m, s, a)
  ^
1 error generated.
*** [i40e_osdep.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/ixl
--- all_subdir_ixgbe ---
--- ixgbe_common.o ---
ctfconvert -L VERSION -g ixgbe_common.o
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/sys/modules/ixgbe
*** [all_subdir_ixgbe] Error code 2

make[3]: stopped in /usr/src/sys/modules
--- all_subdir_ixlv ---
ctfconvert -L VERSION -g if_ixlv.o
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/sys/modules/ixlv
*** [all_subdir_ixlv] Error code 2

make[3]: stopped in /usr/src/sys/modules
--- all_subdir_ixl ---
--- if_ixl.o ---
ctfconvert -L VERSION -g if_ixl.o
1 error

make[4]: stopped in /usr/src/sys/modules/ixl
*** [all_subdir_ixl] Error code 2

make[3]: stopped in /usr/src/sys/modules
3 errors

make[3]: stopped in /usr/src/sys/modules
*** [modules-all] Error code 2

make[2]: stopped in /common/S4/obj/usr/src/sys/CANARY
1 error

make[2]: stopped in /common/S4/obj/usr/src/sys/CANARY
*** [buildkernel] Error code 2

make[1]: stopped in /usr/src
1 error

make[1]: stopped in /usr/src
*** [buildkernel] Error code 2

make: stopped in /usr/src
1 error

make: stopped in /usr/src
.
 stage 3.2: building everything
...


Running:
FreeBSD g1-235.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1354  
r270745M/270748:1100029: Thu Aug 28 06:35:04 PDT 2014 
r...@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386

with sources:
g1-235(11.0-C)[1] svn info /usr/src
Path: /usr/src
Working Copy Root Path: /usr/src
URL: file:///svn/freebsd/src/base/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/src/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 270801
Node Kind: directory
Schedule: normal
Last Changed Author: bz
Last Changed Rev: 270799
Last Changed Date: 2014-08-29 02:37:18 -0700 (Fri, 29 Aug 2014)

g1-235(11.0-C)[2] 

(First encountered during my usual -DNOCLEAN build, so I tried
(just the kernnel) again without -DNOCLEAN; the latter is what I
quoted above.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpnHqPmjB0k7.pgp
Description: PGP signature