pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fwd: Error bootstrapping pkgsrc Q3-2017 on MIPS Linux





On Thu, Nov 23, 2017 at 7:35 AM, Pavel Jirout <freedom.day%gmail.com@localhost> wrote:
Hello,

symlinking of /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include/dlfcn.h   (mounted GCC on USB storage) to /usr/include/dlfcn.h  helped tp get through libtool compile

However during pth build I get yet again header related errors ->

/mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include/bits/pthreadtypes.h:205:3: note: previous declaration of 'pthread_rwlockattr_t' was here
 } pthread_rwlockattr_t;
   ^
In file included from /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include/bits/uClibc_mutex.h:15:0,
                 from /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include/bits/uClibc_stdio.h:107,
                 from /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include/stdio.h:72,
                 from pth_p.h.in:30,
                 from pth_debug.c:29:
./pthread.h:294:42: error: conflicting types for 'pthread_rwlock_t'
 typedef struct  pthread_rwlock_st       *pthread_rwlock_t;
                                          ^
In file included from /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include/bits/types.h:202:0,
                 from /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include/stdio.h:36,
                 from pth_p.h.in:30,
                 from pth_debug.c:29:
/mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include/bits/pthreadtypes.h:199:3: note: previous declaration of 'pthread_rwlock_t' was here
 } pthread_rwlock_t;
   ^
*** Error code 1

Stop.
bmake: stopped in /usr/pkgsrc/bootstrap/work/wrk/devel/pth/work/pth-2.0.7
*** Error code 1


On Tue, Nov 21, 2017 at 10:34 PM, <coypu%sdf.org@localhost> wrote:
On Tue, Nov 21, 2017 at 09:49:00PM +0100, Pavel Jirout wrote:
> Hello,
>
> yes it partially does, in my case I had to add machine_arch=mipseb since my
> device is big endian.
> There are however other issues which most probably relate to the native gcc
> which bail out the following error during devel/libtool-base build
> ERROR: libtool-base-2.4.6 requires a working dlopen()

my little endian 32bit mips is also called mips, so I guess that's not a
good way to tell them apart...  uname -p helpfully returns 'unknown'.

do you have dlfcn.h anywhere? I think that's what the dlopen check
looks for.




Home | Main Index | Thread Index | Old Index