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: OpenSSL 1.1.1 missing shared objects
On Thu, Feb 06, 2020 at 06:22:56AM -0500, Jeffrey Walton wrote: > As long as NetBSD supplies an error when RUNPATH is not supported, I > should be OK. No, it won't error on that test. cc -Wl,--enable-new-dtags works, but the runtime linker ignores DT_RUNPATH. There was a lengthy discussion about this, and a prominent position was that --enable-new-dtags never should be used on NetBSD. However, as you just discoverred, this makes live harder for third party packaging. All newer NetBSD versions just treat DT_RUNPATH the same as DT_RPATH (as it always had the correct semantics on NetBSD). Martin
Re: OpenSSL 1.1.1 missing shared objects
On Thu, Feb 6, 2020 at 6:17 AM Martin Husemann wrote: > > On Thu, Feb 06, 2020 at 06:01:43AM -0500, Jeffrey Walton wrote: > > $ objdump -x /usr/local/bin/openssl | grep -E 'RPATH|RUNPATH' > > RUNPATH $ORIGIN/../lib:/usr/local/lib > > What NetBSD version are you using? NetBSD 8.1, x8686, fully patched: $ cat /etc/release NetBSD 8.1/amd64 > IIRC older version only supported RPATH > in the runtime linker (as that is equivalent to RUNPATH). Newer versions > accept RUNPATH as an alias for RPATH. I perform a feature test for RUNPATH: https://github.com/noloader/Build-Scripts/blob/master/setup-environ.sh#L315 As long as NetBSD supplies an error when RUNPATH is not supported, I should be OK. Jeff
Re: OpenSSL 1.1.1 missing shared objects
On Thu, Feb 06, 2020 at 06:01:43AM -0500, Jeffrey Walton wrote: > $ objdump -x /usr/local/bin/openssl | grep -E 'RPATH|RUNPATH' > RUNPATH $ORIGIN/../lib:/usr/local/lib What NetBSD version are you using? IIRC older version only supported RPATH in the runtime linker (as that is equivalent to RUNPATH). Newer versions accept RUNPATH as an alias for RPATH. 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. > > > > 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
OpenSSL 1.1.1 missing shared objects
Hi Everyone, I've read https://www.netbsd.org/docs/elf.html and I am having trouble understanding some results. I built and installed OpenSSL 1.1.d in prefix=/usr/local. LDFLAGS="-Wl,-R,$$ORIGIN/../lib -Wl,-R,/usr/local/lib -Wl,--enable-new-dtags". Here is the problem: $ /usr/local/bin/openssl version Shared object "libssl.so.1.1" not found Here is what I don't understand: $ ldd /usr/local/bin/openssl /usr/local/bin/openssl: -lssl.1.1 => not found -lcrypto.1.1 => not found -lpthread.1 => /usr/lib/libpthread.so.1 -lc.12 => /usr/lib/libc.so.12 But: $ objdump -x /usr/local/bin/openssl | grep -E 'RPATH|RUNPATH' RUNPATH $ORIGIN/../lib:/usr/local/lib And: $ ls -1 /usr/local/lib | grep -E 'ssl|crypto' libcrypto.a libcrypto.so libcrypto.so.1.1 libssl.a libssl.so libssl.so.1.1 So, the binaries are in the correct location and the runpath has been set, but the openssl program cannot find the libraries. Would someone happen to know why openssl cannot find its shared objects? Thanks in advance.
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?
