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/incl ude/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/incl ude/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/incl ude/bits/uClibc_mutex.h:15:0,
from /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/incl ude/bits/uClibc_stdio.h:107,
from /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/incl ude/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/incl ude/bits/types.h:202:0,
from /mnt/tt/gcc/usr/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/incl ude/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/incl ude/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 1On 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.