Re: Problems with C++ compiler on 9.0_RC2
On Tue, Feb 11, 2020 at 08:28:32PM +, Mike Pumford wrote: > Is /usr/bin/tar bsdtar on 9.0? Yes, and it has been fixed (and the fix pulled up). > Reason I'm asking is that I'm able to compile c++ quite happily in chroot > environments created by un-tarring all the sets into the chroot. using tar > zpxf . So it could be a sysinst upgrade bug. No, it was plain tar fallout. Just extract the base and comp sets again (from a -daily build) and all should be fine. Martin
Re: Problems with C++ compiler on 9.0_RC2
On 2020-02-10 12:46, Marc Baudoin wrote: Martin Husemann écrit : On Mon, Feb 10, 2020 at 01:17:31PM +0100, Marc Baudoin wrote: lrwxr-xr-x 1 martin wheel 12 Jan 31 13:19 ./9.0/usr/include/g++/bits/gthr-default.h@ -> gthr-posix.h -rwxr-xr-x 1 martin wheel 0 Jan 31 13:19 ./updated/usr/include/g++/bits/gthr-default.h* Indeed, I have an empty (executable) /usr/include/g++/bits/gthr-default.h regular file. Replacing it with a symbolic link to gthr-posix.h seems to work (at least your previous example compiles now). Sounds like a bsdtar bug :-( which also explains why it did not happen for your beta updates. Then it would be nice to have it fixed before 9.0. Is /usr/bin/tar bsdtar on 9.0? Reason I'm asking is that I'm able to compile c++ quite happily in chroot environments created by un-tarring all the sets into the chroot. using tar zpxf . So it could be a sysinst upgrade bug. Mike
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit : > On Mon, Feb 10, 2020 at 01:17:31PM +0100, Marc Baudoin wrote: > > Strangely enough, it doesn't happen on another system that have > > been upgraded (always with a binary install image) from 8.1 to > > several 9.0_BETAs over time then 9.0_RC1 then 9.0_RC2... > > The difference is: > > lrwxr-xr-x 1 martin wheel 12 Jan 31 13:19 > ./9.0/usr/include/g++/bits/gthr-default.h@ -> gthr-posix.h > -rwxr-xr-x 1 martin wheel 0 Jan 31 13:19 > ./updated/usr/include/g++/bits/gthr-default.h* Indeed, I have an empty (executable) /usr/include/g++/bits/gthr-default.h regular file. Replacing it with a symbolic link to gthr-posix.h seems to work (at least your previous example compiles now). > Sounds like a bsdtar bug :-( which also explains why it did not happen > for your beta updates. Then it would be nice to have it fixed before 9.0. Thanks!
Re: Problems with C++ compiler on 9.0_RC2
On Mon, Feb 10, 2020 at 01:17:31PM +0100, Marc Baudoin wrote: > Strangely enough, it doesn't happen on another system that have > been upgraded (always with a binary install image) from 8.1 to > several 9.0_BETAs over time then 9.0_RC1 then 9.0_RC2... The difference is: lrwxr-xr-x 1 martin wheel 12 Jan 31 13:19 ./9.0/usr/include/g++/bits/gthr-default.h@ -> gthr-posix.h -rwxr-xr-x 1 martin wheel 0 Jan 31 13:19 ./updated/usr/include/g++/bits/gthr-default.h* Sounds like a bsdtar bug :-( which also explains why it did not happen for your beta updates. Martin
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit :
> On Mon, Feb 10, 2020 at 11:01:37AM +0100, Marc Baudoin wrote:
> > I believe only C++ programs using pthread fail. I don't know how
> > to do a minimal example but the easiest way to see the problem is
> > to compile pkgsrc/multimedia/libvpx (which doesn't have too many
> > dependencies).
>
> Here is a trivial reproducer:
>
> --8<--
> #include
> #include
> using namespace std;
>
> int main(int argc, char **argv)
> {
> cout << "hello world\n";
> return 0;
> }
> -->8--
Thanks.
> Compile with c++ and watch it fail as you described.
>
> The original compilation was done with -std=c++11, but that does not seem
> to matter here.
It doesn't matter indeed, it always fail for me:
% c++ -std=c++11 toto.cxx
In file included from /usr/include/g++/memory:74:0,
from toto.cxx:1:
/usr/include/g++/ext/concurrence.h:124:5: error: ‘__gthread_mutex_t’ does not
name a type; did you mean ‘__pthread_volatile’?
__gthread_mutex_t _M_mutex;
^
__pthread_volatile
/usr/include/g++/ext/concurrence.h:169:5: error: ‘__gthread_mutex_t’ does not
name a type; did you mean ‘__pthread_volatile’?
__gthread_mutex_t* gthread_mutex(void)
^
__pthread_volatile
/usr/include/g++/ext/concurrence.h:179:5: error: ‘__gthread_recursive_mutex_t’
does not name a type; did you mean ‘__recursive_mutex’?
__gthread_recursive_mutex_t _M_mutex;
^~~
__recursive_mutex
/usr/include/g++/ext/concurrence.h:224:5: error: ‘__gthread_recursive_mutex_t’
does not name a type; did you mean ‘__recursive_mutex’?
__gthread_recursive_mutex_t* gthread_recursive_mutex(void)
^~~
__recursive_mutex
> The failure (at least with above test) does not happen in -current, nor
> when installing 9.0_RC2 from scratch.
But it happens for me on every system I have that have been
upgraded with an install ISO from 8.1 to 9.0_RC2.
Strangely enough, it doesn't happen on another system that have
been upgraded (always with a binary install image) from 8.1 to
several 9.0_BETAs over time then 9.0_RC1 then 9.0_RC2...
Re: Problems with C++ compiler on 9.0_RC2
On Mon, Feb 10, 2020 at 11:01:37AM +0100, Marc Baudoin wrote:
> I believe only C++ programs using pthread fail. I don't know how
> to do a minimal example but the easiest way to see the problem is
> to compile pkgsrc/multimedia/libvpx (which doesn't have too many
> dependencies).
Here is a trivial reproducer:
--8<--
#include
#include
using namespace std;
int main(int argc, char **argv)
{
cout << "hello world\n";
return 0;
}
-->8--
Compile with c++ and watch it fail as you described.
The original compilation was done with -std=c++11, but that does not seem
to matter here.
The failure (at least with above test) does not happen in -current, nor
when installing 9.0_RC2 from scratch.
Martin
Re: Problems with C++ compiler on 9.0_RC2
On Thu, Feb 6, 2020 at 11:10 AM Marc Baudoin wrote: [...] > Is it a problem with my setup, with pkgsrc or is there something > wrong with the C++ environment in 9.0_RC2? cmake compiled fine on my fresh install of rc2
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit : > On Mon, Feb 10, 2020 at 08:07:07AM +0100, Marc Baudoin wrote: > > I just tried : > > > > - install NetBSD/amd64 8.1 from ISO > > - boot from 9.0_RC2 ISO and upgrade > > - reboot, get pkgsrc: any C++ build will fail > > Can you try a minimal C++ hello world program? > > I tried your recipe with i386 and at last hello world in c++ did work just > fine. I believe only C++ programs using pthread fail. I don't know how to do a minimal example but the easiest way to see the problem is to compile pkgsrc/multimedia/libvpx (which doesn't have too many dependencies).
Re: Problems with C++ compiler on 9.0_RC2
On Mon, Feb 10, 2020 at 08:07:07AM +0100, Marc Baudoin wrote: > I just tried : > > - install NetBSD/amd64 8.1 from ISO > - boot from 9.0_RC2 ISO and upgrade > - reboot, get pkgsrc: any C++ build will fail Can you try a minimal C++ hello world program? I tried your recipe with i386 and at last hello world in c++ did work just fine. The exact failure may depend on the version of the c++ standard that is requested on the command line or something. Martin
Re: Problems with C++ compiler on 9.0_RC2
Kamil Rytarowski écrit : > On 06.02.2020 10:09, Marc Baudoin wrote: > > > > I recently upgraded a NetBSD/amd64 8.1 system to 9.0_RC2 and I > > noticed problems when compiling C++ programs. > > Please share a minimal reproducer. I just tried : - install NetBSD/amd64 8.1 from ISO - boot from 9.0_RC2 ISO and upgrade - reboot, get pkgsrc: any C++ build will fail
Re: Problems with C++ compiler on 9.0_RC2
On 06/02/2020 23:30, Mike Pumford wrote: I'm not building 9.0-RC packages on i386 yet but I can say that on amd64 with 9.0 pkgsrc current from 02 Feb 0710am UTC and 9.0RC1 01 Feb 0745 UTC that cmake certainly works. These are builds in a chroot so they are guaranteed to have a totally clean tree to start with. I've just kicked off some fresh 9.0RC system builds for i386 and amd64 and I'll follow that with a pkgsrc-current run and see if I can reproduce. Okay. My last build was a RC2 userland with an RC1 kernel from a week ago. I'll upgrade and go straight to the pkgsrc builds ;) Mike
Re: Problems with C++ compiler on 9.0_RC2
On 06/02/2020 11:40, Manuel Bouyer wrote: On Thu, Feb 06, 2020 at 12:13:31PM +0100, Marc Baudoin wrote: [...] I can't because I gave up on C++ some 20 years ago. Anyway, trying to compile pkgsrc/devel/cmake or pkgsrc/print/poppler fails every time for me as indicated in my previous message. It could also be a pthreads problem. But it's definitely linked to 9.0_RC2 as I didn't have it with 8.1. I guess it's from pkgsrc-current ? I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did build fine. I'm not building 9.0-RC packages on i386 yet but I can say that on amd64 with 9.0 pkgsrc current from 02 Feb 0710am UTC and 9.0RC1 01 Feb 0745 UTC that cmake certainly works. These are builds in a chroot so they are guaranteed to have a totally clean tree to start with. I've just kicked off some fresh 9.0RC system builds for i386 and amd64 and I'll follow that with a pkgsrc-current run and see if I can reproduce. Mike
Re: Problems with C++ compiler on 9.0_RC2
Greg Troxel écrit : > Marc Baudoin writes: > > >> I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did > >> build > >> fine. > > > > Then can it be because of some leftover files from a previous > > version (the machine I have the problem on has seen every NetBSD > > version since 2013)? > > Yes, it could be. There is stuff in /usr/include/g++, and you need to > make sure you have only the bits that correspond to your installed > system version. > > Two things: > > postinstall check (and then fix) It has already been done in the upgrade process (I do it with sysinst while booting on an install USB stick and this is done after unpacking the new sets). > look in /usr/include for files that have a ctime greater than when you > unpacked the new sets. remove the old ones.Alternatively, unpack > the sets in a directory someplace and compare. Everything checks out, there are no leftover files in /usr/include...
Re: Problems with C++ compiler on 9.0_RC2
Marc Baudoin writes: >> I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did >> build >> fine. > > Then can it be because of some leftover files from a previous > version (the machine I have the problem on has seen every NetBSD > version since 2013)? Yes, it could be. There is stuff in /usr/include/g++, and you need to make sure you have only the bits that correspond to your installed system version. Two things: postinstall check (and then fix) look in /usr/include for files that have a ctime greater than when you unpacked the new sets. remove the old ones.Alternatively, unpack the sets in a directory someplace and compare.
Re: Problems with C++ compiler on 9.0_RC2
Manuel Bouyer écrit : > On Thu, Feb 06, 2020 at 12:13:31PM +0100, Marc Baudoin wrote: > > [...] > > I can't because I gave up on C++ some 20 years ago. Anyway, > > trying to compile pkgsrc/devel/cmake or pkgsrc/print/poppler > > fails every time for me as indicated in my previous message. > > > > It could also be a pthreads problem. But it's definitely linked > > to 9.0_RC2 as I didn't have it with 8.1. > > I guess it's from pkgsrc-current ? Yes it is. > I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did > build > fine. Then can it be because of some leftover files from a previous version (the machine I have the problem on has seen every NetBSD version since 2013)?
Re: Problems with C++ compiler on 9.0_RC2
On Thu, Feb 06, 2020 at 12:13:31PM +0100, Marc Baudoin wrote: > [...] > I can't because I gave up on C++ some 20 years ago. Anyway, > trying to compile pkgsrc/devel/cmake or pkgsrc/print/poppler > fails every time for me as indicated in my previous message. > > It could also be a pthreads problem. But it's definitely linked > to 9.0_RC2 as I didn't have it with 8.1. I guess it's from pkgsrc-current ? I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did build fine. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Problems with C++ compiler on 9.0_RC2
Kamil Rytarowski écrit : > On 06.02.2020 10:09, Marc Baudoin wrote: > > > > I recently upgraded a NetBSD/amd64 8.1 system to 9.0_RC2 and I > > noticed problems when compiling C++ programs. > > > > For instance, with pkgsrc/devel/cmake: [...] > > or with pkgsrc/print/poppler: > > Please share a minimal reproducer. I can't because I gave up on C++ some 20 years ago. Anyway, trying to compile pkgsrc/devel/cmake or pkgsrc/print/poppler fails every time for me as indicated in my previous message. It could also be a pthreads problem. But it's definitely linked to 9.0_RC2 as I didn't have it with 8.1.
Re: Problems with C++ compiler on 9.0_RC2
On 06.02.2020 10:09, Marc Baudoin wrote: > Hi, > > I recently upgraded a NetBSD/amd64 8.1 system to 9.0_RC2 and I > noticed problems when compiling C++ programs. > > For instance, with pkgsrc/devel/cmake: > > In file included from /usr/include/g++/memory:74:0, > from cmake_bootstrap_13004_test.cxx:3: > /usr/include/g++/ext/concurrence.h:124:5: error: '__gthread_mutex_t' does not > name a type; did you mean '__pthread_mutex_st'? > __gthread_mutex_t _M_mutex; > ^ > __pthread_mutex_st > /usr/include/g++/ext/concurrence.h:169:5: error: '__gthread_mutex_t' does not > name a type; did you mean '__pthread_mutex_st'? > __gthread_mutex_t* gthread_mutex(void) > ^ > __pthread_mutex_st > /usr/include/g++/ext/concurrence.h:179:5: error: > '__gthread_recursive_mutex_t' does not name a type; did you mean > '__recursive_mutex'? > __gthread_recursive_mutex_t _M_mutex; > ^~~ > [...] > > or with pkgsrc/print/poppler: > > In file included from /usr/include/g++/mutex:43:0, > from > /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Array.h:32, > from > /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Object.h:335, > from > /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Annot.cc:61: > /usr/include/g++/bits/std_mutex.h:63:13: error: '__gthread_mutex_t' does not > name a type; did you mean '__pthread_mutex_st'? > typedef __gthread_mutex_t __native_type; > ^ > __pthread_mutex_st > /usr/include/g++/bits/std_mutex.h:70:5: error: '__native_type' does not name > a type; did you mean '__false_type'? > __native_type _M_mutex; > ^ > __false_type > /usr/include/g++/bits/std_mutex.h: In constructor > 'std::__mutex_base::__mutex_base()': > /usr/include/g++/bits/std_mutex.h:75:38: error: '_M_mutex' was not declared > in this scope >__GTHREAD_MUTEX_INIT_FUNCTION(&_M_mutex); > ^~~~ > > Is it a problem with my setup, with pkgsrc or is there something > wrong with the C++ environment in 9.0_RC2? > Please share a minimal reproducer. signature.asc Description: OpenPGP digital signature
Problems with C++ compiler on 9.0_RC2
Hi, I recently upgraded a NetBSD/amd64 8.1 system to 9.0_RC2 and I noticed problems when compiling C++ programs. For instance, with pkgsrc/devel/cmake: In file included from /usr/include/g++/memory:74:0, from cmake_bootstrap_13004_test.cxx:3: /usr/include/g++/ext/concurrence.h:124:5: error: '__gthread_mutex_t' does not name a type; did you mean '__pthread_mutex_st'? __gthread_mutex_t _M_mutex; ^ __pthread_mutex_st /usr/include/g++/ext/concurrence.h:169:5: error: '__gthread_mutex_t' does not name a type; did you mean '__pthread_mutex_st'? __gthread_mutex_t* gthread_mutex(void) ^ __pthread_mutex_st /usr/include/g++/ext/concurrence.h:179:5: error: '__gthread_recursive_mutex_t' does not name a type; did you mean '__recursive_mutex'? __gthread_recursive_mutex_t _M_mutex; ^~~ [...] or with pkgsrc/print/poppler: In file included from /usr/include/g++/mutex:43:0, from /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Array.h:32, from /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Object.h:335, from /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Annot.cc:61: /usr/include/g++/bits/std_mutex.h:63:13: error: '__gthread_mutex_t' does not name a type; did you mean '__pthread_mutex_st'? typedef __gthread_mutex_t __native_type; ^ __pthread_mutex_st /usr/include/g++/bits/std_mutex.h:70:5: error: '__native_type' does not name a type; did you mean '__false_type'? __native_type _M_mutex; ^ __false_type /usr/include/g++/bits/std_mutex.h: In constructor 'std::__mutex_base::__mutex_base()': /usr/include/g++/bits/std_mutex.h:75:38: error: '_M_mutex' was not declared in this scope __GTHREAD_MUTEX_INIT_FUNCTION(&_M_mutex); ^~~~ Is it a problem with my setup, with pkgsrc or is there something wrong with the C++ environment in 9.0_RC2?
