• Cross-Compiling for Zyxel NSA221 NAS

    From Java Jive@110:300/11 to All on Wed Mar 28 14:32:40 2018
    (was 'Choosing a board for a NAS/SAN/Object storage', and before I say anything else, thanks to J O Aho for his helpful reply there, but I
    don't want to hijack that thread, so have started this new one)

    You will recall that I wrote:

    I've built my own cross-chain running under
    Ubuntu 16.04 on one of my laptops, but, although this seems to work and
    can cross-compile simple programmes, such as binutils for example, it
    cannot cross-compile gcc or glibc, again after a while there is a show stopping error.

    Here is a typical case in point. This morning I have successfully cross-compiled - by which I mean that the compilation and installation
    into the arm sysroot completed successfully, but whether the binaries
    created will actually run on the arm hardware is yet to be tested -
    the following ...
    cups
    curl
    dhcpcd
    expat
    fuse
    libiconv
    openssl
    pcre
    pure-ftpd
    zlib

    For most of them, all except one I think, the cross-compilation was
    achieved by giving configure the following parameters ...
    --build=${BUILD} --host=${HOST}
    .... where ...
    BUILD Describes the build system, Ubuntu 16.04 64-bit
    HOST armv5tejl-unknown-linux-gnueabi
    .... but trying to cross-compile Apache, both versions 2.4.29 and 2.4.33,
    with the same configuration parameters, fails with the following:

    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libtool --silent --mode=link armv5tejl-unknown-linux-gnueabi-gcc -std=gnu99 -g -O2
    -o httpd modules.lo buildmark.o -export-dynamic server/libmain.la modules/core/libmod_so.la modules/http/libmod_http.la server/mpm/event/libevent.la os/unix/libos.la -lpcre /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr-util/libaprutil-1.la -lexpat -liconv /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libapr-1.la -lrt -lcrypt -ldl /home/zyxel-nas/NSA-221-GPL/test/arm/xtools/lib/gcc/armv5tejl-unknown-linux-gnueabi/4.9.4/../../../../armv5tejl-unknown-linux-gnueabi/bin/ld:
    server/mpm/event/.libs/libevent.a(event.o): undefined reference to
    symbol 'pthread_sigmask@@GLIBC_2.4' /home/zyxel-nas/NSA-221-GPL/test/arm/sysroot/lib/libpthread.so.0: error
    adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/program.mk:22: recipe
    for target 'httpd' failed
    make[1]: *** [httpd] Error 1
    make[1]: Leaving directory '/home/zyxel-nas/NSA-221-GPL/test/build/httpd' /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:75: recipe
    for target 'all-recursive' failed
    make: *** [all-recursive] Error 1

    I have no idea what to make of this. I found nothing on the web that
    seemed helpful, the sysroot contains GLibC v2.18, not v2.4, and WTF does
    'DSO missing from command line' mean in plain English? Something
    missing from a command line I can understand, but which command-line and
    what is DSO (apart from Digital Switch Over, which doesn't seem likely
    to be relevant)!

    Any suggestions to help me cross-compile Apache would be gratefully
    received.

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (110:300/11@linuxnet)
  • From Steven Petruzzellis@110:300/11 to All on Wed Mar 28 15:23:19 2018
    On Wednesday, March 28, 2018 at 5:32:47 AM UTC-7, Java Jive wrote:
    (was 'Choosing a board for a NAS/SAN/Object storage', and before I say=20 anything else, thanks to J O Aho for his helpful reply there, but I=20
    don't want to hijack that thread, so have started this new one)
    =20
    You will recall that I wrote:
    =20
    I've built my own cross-chain running under
    Ubuntu 16.04 on one of my laptops, but, although this seems to work an=
    d
    can cross-compile simple programmes, such as binutils for example, it cannot cross-compile gcc or glibc, again after a while there is a show stopping error.
    =20
    Here is a typical case in point. This morning I have successfully=20 cross-compiled - by which I mean that the compilation and installation=
    =20
    into the arm sysroot completed successfully, but whether the binaries=20 created will actually run on the arm hardware is yet to be tested -=20
    the following ...
    cups
    curl
    dhcpcd
    expat
    fuse
    libiconv
    openssl
    pcre
    pure-ftpd
    zlib
    =20
    For most of them, all except one I think, the cross-compilation was=20 achieved by giving configure the following parameters ...
    --build=3D${BUILD} --host=3D${HOST}
    ... where ...
    BUILD Describes the build system, Ubuntu 16.04 64-bit
    HOST armv5tejl-unknown-linux-gnueabi
    ... but trying to cross-compile Apache, both versions 2.4.29 and 2.4.33,=
    =20
    with the same configuration parameters, fails with the following:
    =20
    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libtool --silent=
    =20
    --mode=3Dlink armv5tejl-unknown-linux-gnueabi-gcc -std=3Dgnu99 -g -O2=20
    -o httpd modules.lo buildmark.o -export-dynamic server/libmain.la=20 modules/core/libmod_so.la modules/http/libmod_http.la=20 server/mpm/event/libevent.la os/unix/libos.la -lpcre=20 /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr-util/libaprutil-1=
    ..la=20
    -lexpat -liconv=20 /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libapr-1.la -lrt=
    =20
    -lcrypt -ldl /home/zyxel-nas/NSA-221-GPL/test/arm/xtools/lib/gcc/armv5tejl-unknown-lin=
    ux-gnueabi/4.9.4/../../../../armv5tejl-unknown-linux-gnueabi/bin/ld:=20
    server/mpm/event/.libs/libevent.a(event.o): undefined reference to=20
    symbol 'pthread_sigmask@@GLIBC_2.4' /home/zyxel-nas/NSA-221-GPL/test/arm/sysroot/lib/libpthread.so.0: error=
    =20
    adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/program.mk:22: recipe=
    =20
    for target 'httpd' failed
    make[1]: *** [httpd] Error 1
    make[1]: Leaving directory '/home/zyxel-nas/NSA-221-GPL/test/build/httpd' /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:75: recipe=20
    for target 'all-recursive' failed
    make: *** [all-recursive] Error 1
    =20
    I have no idea what to make of this. I found nothing on the web that=20 seemed helpful, the sysroot contains GLibC v2.18, not v2.4, and WTF does=
    =20
    'DSO missing from command line' mean in plain English? Something=20
    missing from a command line I can understand, but which command-line and=
    =20
    what is DSO (apart from Digital Switch Over, which doesn't seem likely=20
    to be relevant)!
    =20
    Any suggestions to help me cross-compile Apache would be gratefully=20 received.



    And in response you have nothing but an attempt to start more flooding. Per= haps you use it wrong. Do you not understand the use of VPN?=20

    Autumn Elizabeth Nissen's toned down the nonstop egotistical, insane thread=
    s he used to write but he is surely unchanged in the truthfulness territory=
    .. He uses sock puppets more to create those threads. Both of those guys get=
    their kicks out of provoking annoyed responses to their flooding, which is=
    the very definition of a troll. No one who isn't just using you for trolli=
    ng goals (isn't a sock) sees you as anything remotely close to good. You ha=
    ve no one but Autumn Elizabeth Nissen to credit for that. Autumn Elizabeth = Nissen proved himself to be a sophist by claiming he would not argue with j= acobnavia through vehemently screaming 'score: -999' and then bombarding hi=
    m repeatedly through piggybacking.=20



    --
    Best CMS Solution of 2017 https://groups.google.com/forum/#!topic/comp.sys.mac.system/6m_7Z7rQ6Hg https://youtu.be/HHT9SJgYsH4
    https://www.youtube.com/watch?v=3D0ZNxaaKD7-c
    Jonas Eklundh

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: The Kofo System II BBS (110:300/11@linuxnet)
  • From Java Jive@110:300/11 to All on Wed Mar 28 23:23:09 2018
    On 28/03/2018 13:32, Java Jive wrote:
    (was 'Choosing a board for a NAS/SAN/Object storage', and before I say anything else, thanks to J O Aho for his helpful reply there, but I
    don't want to hijack that thread, so have started this new one)

    You will recall that I wrote:

    I've built my own cross-chain running under
    Ubuntu 16.04 on one of my laptops, but, although this seems to work and can cross-compile simple programmes, such as binutils for example, it cannot cross-compile gcc or glibc, again after a while there is a show stopping error.

    Here is a typical case in point.  This morning I have successfully cross-compiled  -  by which I mean that the compilation and installation into the arm sysroot completed successfully, but whether the binaries created will actually run on the arm hardware is yet to be tested  - the following ...
        cups
        curl
        dhcpcd
        expat
        fuse
        libiconv
        openssl
        pcre
        pure-ftpd
        zlib

    For most of them, all except one I think, the cross-compilation was
    achieved by giving configure the following parameters ...
        --build=${BUILD} --host=${HOST}
    ... where ...
        BUILD    Describes the build system, Ubuntu 16.04 64-bit
        HOST    armv5tejl-unknown-linux-gnueabi
    ... but trying to cross-compile Apache, both versions 2.4.29 and 2.4.33, with the same configuration parameters, fails with the following:

    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libtool --silent --mode=link armv5tejl-unknown-linux-gnueabi-gcc -std=gnu99  -g -O2   -o httpd  modules.lo buildmark.o -export-dynamic server/libmain.la modules/core/libmod_so.la modules/http/libmod_http.la server/mpm/event/libevent.la os/unix/libos.la -lpcre /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr-util/libaprutil-1.la -lexpat -liconv /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libapr-1.la -lrt -lcrypt -ldl /home/zyxel-nas/NSA-221-GPL/test/arm/xtools/lib/gcc/armv5tejl-unknown-linux-gnueabi/4.9.4/../../../../armv5tejl-unknown-linux-gnueabi/bin/ld:
    server/mpm/event/.libs/libevent.a(event.o): undefined reference to
    symbol 'pthread_sigmask@@GLIBC_2.4' /home/zyxel-nas/NSA-221-GPL/test/arm/sysroot/lib/libpthread.so.0: error adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/program.mk:22: recipe
    for target 'httpd' failed
    make[1]: *** [httpd] Error 1
    make[1]: Leaving directory '/home/zyxel-nas/NSA-221-GPL/test/build/httpd' /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:75: recipe
    for target 'all-recursive' failed
    make: *** [all-recursive] Error 1

    I have no idea what to make of this.  I found nothing on the web that
    seemed helpful, the sysroot contains GLibC v2.18, not v2.4, and WTF does 'DSO missing from command line' mean in plain English?  Something
    missing from a command line I can understand, but which command-line and what is DSO (apart from Digital Switch Over, which doesn't seem likely
    to be relevant)!

    Any suggestions to help me cross-compile Apache would be gratefully received.

    11 hours later, most of which has been spent at the problem, and I'm no further along. I've tried:

    - Thinking that it might be related to the order of the libraries being presented on that command-line, pre-compiling and installing into the
    arm sysroot the dependencies apr, apr-util, and pcre, which took a long
    time to get right, but in the end the same error still happens at the
    same place.

    - The last 2.2 version, 2.2.9, which gives a different error, again
    regardless of whether the dependencies are pre-compiled and installed or
    not. The 2.2 error is:

    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libtool --silent --mode=compile armv5tejl-unknown-linux-gnueabi-gcc -g -O2
    -I/usr/local/include -D_REENTRANT -D_GNU_SOURCE -I. -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/os/unix -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/server/mpm/prefork -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/http -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/filters -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/proxy -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/include -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/generators -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/mappers -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/database -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/include -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr-util/include -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/proxy/../generators -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/ssl -I/home/zyxel-nas/NSA-221-GPL/test/build/httpd/modules/dav/main -prefer-non-pic -static -c core.c && touch core.lo
    core.c: In function ΓÇÿcreate_core_dir_configΓÇÖ:
    core.c:127:9: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_cpuΓÇÖ
    conf->limit_cpu = NULL;
    ^
    core.c:130:9: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_memΓÇÖ
    conf->limit_mem = NULL;
    ^
    core.c:133:9: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_nprocΓÇÖ
    conf->limit_nproc = NULL;
    ^
    core.c: In function ΓÇÿmerge_core_dir_configsΓÇÖ:
    core.c:322:12: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_cpuΓÇÖ
    if (new->limit_cpu) {
    ^
    core.c:323:13: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_cpuΓÇÖ
    conf->limit_cpu = new->limit_cpu;
    ^
    core.c:323:30: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_cpuΓÇÖ
    conf->limit_cpu = new->limit_cpu;
    ^
    core.c:328:12: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_memΓÇÖ
    if (new->limit_mem) {
    ^
    core.c:329:13: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_memΓÇÖ
    conf->limit_mem = new->limit_mem;
    ^
    core.c:329:30: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_memΓÇÖ
    conf->limit_mem = new->limit_mem;
    ^
    core.c:334:12: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_nprocΓÇÖ
    if (new->limit_nproc) {
    ^
    core.c:335:13: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_nprocΓÇÖ
    conf->limit_nproc = new->limit_nproc;
    ^
    core.c:335:32: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_nprocΓÇÖ
    conf->limit_nproc = new->limit_nproc;
    ^
    core.c: In function ΓÇÿset_limit_cpuΓÇÖ:
    core.c:2972:32: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_cpuΓÇÖ
    unixd_set_rlimit(cmd, &conf->limit_cpu, arg, arg2, RLIMIT_CPU);
    ^
    core.c: In function ΓÇÿset_limit_memΓÇÖ:
    core.c:2984:32: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_memΓÇÖ
    unixd_set_rlimit(cmd, &conf->limit_mem, arg, arg2 ,RLIMIT_AS);
    ^
    core.c: In function ΓÇÿset_limit_nprocΓÇÖ:
    core.c:3001:32: error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_nprocΓÇÖ
    unixd_set_rlimit(cmd, &conf->limit_nproc, arg, arg2, RLIMIT_NPROC);
    ^
    In file included from core.c:33:0:
    core.c: At top level: /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/include/apr_general.h:96:45:
    error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_cpuΓÇÖ
    ((long) (((char *) (&(((p_type)NULL)->field))) - ((char *) NULL)))
    ^ /home/zyxel-nas/NSA-221-GPL/test/build/httpd/include/http_config.h:136:35: note: in definition of macro ΓÇÿAP_INIT_TAKE12ΓÇÖ
    { directive, { .take2=func }, mconfig, where, TAKE12, help }
    ^ /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/include/apr_general.h:109:36:
    note: in expansion of macro ΓÇÿAPR_OFFSETΓÇÖ
    #define APR_OFFSETOF(s_type,field) APR_OFFSET(s_type*,field)
    ^
    core.c:3376:10: note: in expansion of macro ΓÇÿAPR_OFFSETOFΓÇÖ
    (void*)APR_OFFSETOF(core_dir_config, limit_cpu),
    ^ /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/include/apr_general.h:96:45:
    error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_memΓÇÖ
    ((long) (((char *) (&(((p_type)NULL)->field))) - ((char *) NULL)))
    ^ /home/zyxel-nas/NSA-221-GPL/test/build/httpd/include/http_config.h:136:35: note: in definition of macro ΓÇÿAP_INIT_TAKE12ΓÇÖ
    { directive, { .take2=func }, mconfig, where, TAKE12, help }
    ^ /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/include/apr_general.h:109:36:
    note: in expansion of macro ΓÇÿAPR_OFFSETΓÇÖ
    #define APR_OFFSETOF(s_type,field) APR_OFFSET(s_type*,field)
    ^
    core.c:3384:10: note: in expansion of macro ΓÇÿAPR_OFFSETOFΓÇÖ
    (void*)APR_OFFSETOF(core_dir_config, limit_mem),
    ^ /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/include/apr_general.h:96:45:
    error: ΓÇÿcore_dir_configΓÇÖ has no member named ΓÇÿlimit_nprocΓÇÖ
    ((long) (((char *) (&(((p_type)NULL)->field))) - ((char *) NULL)))
    ^ /home/zyxel-nas/NSA-221-GPL/test/build/httpd/include/http_config.h:136:35: note: in definition of macro ΓÇÿAP_INIT_TAKE12ΓÇÖ
    { directive, { .take2=func }, mconfig, where, TAKE12, help }
    ^ /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/include/apr_general.h:109:36:
    note: in expansion of macro ΓÇÿAPR_OFFSETΓÇÖ
    #define APR_OFFSETOF(s_type,field) APR_OFFSET(s_type*,field)
    ^
    core.c:3392:10: note: in expansion of macro ΓÇÿAPR_OFFSETOFΓÇÖ
    (void*)APR_OFFSETOF(core_dir_config, limit_nproc),
    ^
    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:194: recipe
    for target 'core.lo' failed
    make[2]: *** [core.lo] Error 1
    make[2]: Leaving directory '/home/zyxel-nas/NSA-221-GPL/test/build/httpd/server' /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:72: recipe
    for target 'all-recursive' failed
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory '/home/zyxel-nas/NSA-221-GPL/test/build/httpd/server' /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:72: recipe
    for target 'all-recursive' failed
    make: *** [all-recursive] Error 1

    So I'm mega pissed-off, nobody's paying me to waste my time on other
    people's poorly tested crap - why can't they at least try
    cross-compiling their own sources themselves, you don't actually need
    any 'foreign' hardware to check that it actually cross-compiles without
    error, do you?

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (110:300/11@linuxnet)
  • From Richard Kettlewell@110:300/11 to All on Thu Mar 29 00:19:32 2018
    Java Jive <java@evij.com.invalid> writes:
    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libtool
    --silent --mode=link armv5tejl-unknown-linux-gnueabi-gcc -std=gnu99
    -g -O2 -o httpd modules.lo buildmark.o -export-dynamic
    server/libmain.la modules/core/libmod_so.la
    modules/http/libmod_http.la server/mpm/event/libevent.la
    os/unix/libos.la -lpcre /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr-util/libaprutil-1.la -lexpat -liconv /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libapr-1.la
    -lrt -lcrypt -ldl /home/zyxel-nas/NSA-221-GPL/test/arm/xtools/lib/gcc/armv5tejl-unknown-linux-gnueabi/4.9.4/../../../../armv5tejl-unknown-linux-gnueabi/bin/ld:
    server/mpm/event/.libs/libevent.a(event.o): undefined reference to
    symbol 'pthread_sigmask@@GLIBC_2.4' /home/zyxel-nas/NSA-221-GPL/test/arm/sysroot/lib/libpthread.so.0:
    error adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/program.mk:22:
    recipe for target 'httpd' failed
    make[1]: *** [httpd] Error 1
    make[1]: Leaving directory '/home/zyxel-nas/NSA-221-GPL/test/build/httpd' /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:75: recipe
    for target 'all-recursive' failed
    make: *** [all-recursive] Error 1

    I have no idea what to make of this. I found nothing on the web that
    seemed helpful, the sysroot contains GLibC v2.18, not v2.4,

    ThatΓÇÖs a symbol version, not the library version.

    and WTF does 'DSO missing from command line' mean in plain English?
    Something missing from a command line I can understand, but which command-line and what is DSO (apart from Digital Switch Over, which
    doesn't seem likely to be relevant)!

    The previous error is a better hint: something needs pthread_sigmask but
    no library provides it. AFAIK this is normally resolved automatically
    (shared libraries list their dependencies; perhaps something in the way
    the crossbuild environment is set up has broken this. At any rate the
    answer is probably to add -lpthread.

    --
    https://www.greenend.org.uk/rjk/

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: terraraq NNTP server (110:300/11@linuxnet)
  • From Steven Petruzzellis@110:300/11 to All on Thu Mar 29 03:05:30 2018
    On Wednesday, March 28, 2018 at 3:19:33 PM UTC-7, Richard Kettlewell wrote:
    Java Jive <java@evij.com.invalid> writes:
    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libtool
    --silent --mode=3Dlink armv5tejl-unknown-linux-gnueabi-gcc -std=3Dgnu99
    -g -O2 -o httpd modules.lo buildmark.o -export-dynamic
    server/libmain.la modules/core/libmod_so.la
    modules/http/libmod_http.la server/mpm/event/libevent.la
    os/unix/libos.la -lpcre /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr-util/libaprutil=
    -1.la
    -lexpat -liconv /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libapr-1.la
    -lrt -lcrypt -ldl /home/zyxel-nas/NSA-221-GPL/test/arm/xtools/lib/gcc/armv5tejl-unknown-l=
    inux-gnueabi/4.9.4/../../../../armv5tejl-unknown-linux-gnueabi/bin/ld:
    server/mpm/event/.libs/libevent.a(event.o): undefined reference to
    symbol 'pthread_sigmask@@GLIBC_2.4' /home/zyxel-nas/NSA-221-GPL/test/arm/sysroot/lib/libpthread.so.0:
    error adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/program.mk:22:
    recipe for target 'httpd' failed
    make[1]: *** [httpd] Error 1
    make[1]: Leaving directory '/home/zyxel-nas/NSA-221-GPL/test/build/http=
    d'
    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:75: recipe
    for target 'all-recursive' failed
    make: *** [all-recursive] Error 1

    I have no idea what to make of this. I found nothing on the web that seemed helpful, the sysroot contains GLibC v2.18, not v2.4,
    =20
    That=E2=80=99s a symbol version, not the library version.
    =20
    and WTF does 'DSO missing from command line' mean in plain English? Something missing from a command line I can understand, but which command-line and what is DSO (apart from Digital Switch Over, which
    doesn't seem likely to be relevant)!
    =20
    The previous error is a better hint: something needs pthread_sigmask but
    no library provides it. AFAIK this is normally resolved automatically
    (shared libraries list their dependencies; perhaps something in the way
    the crossbuild environment is set up has broken this. At any rate the
    answer is probably to add -lpthread.
    =20
    --=20
    https://www.greenend.org.uk/rjk/



    Facts about Steve "Steven Petruzzellis" Carroll

    Steve "Steven Petruzzellis" Carroll is a nearly 60 year old guy who is sing= le, broke and has no skills. He blames Owl for his loss of his wife and gir= lfriend. Steven is jealous of what Owl has and in a narcissistic rage repea= tedly works to take it away from him. For over 10 years he has failed at ev=
    en this. Steve "Steven Petruzzellis" Carroll is an utter failure in life.

    Of his online life Steven says

    I've been booted off by past providers before because people
    complain about me and all my bullshit. I don't want to lose my ISP
    *again* but I still need my army of sock puppets so I continually
    search usenet for whatever servers I haven't yet been booted
    from.
    =20
    Some examples where Steven has been booted

    X10 Hosting booted Steven for inappropriate activity
    http://tinyurl.com/z92qmz4

    Comcast booted Steven for inappropriate activity=20
    http://tinyurl.com/h75nh9l

    FreeHostingEU booted Steven for copyright infringement http://devsite.eu.pn

    AwardSpace (atwebpages.com) booted Steven for breaking terms of service http://demsites.atwebpages.com/pokeman

    Imgur took down an image for breaking terms of service http://imgur.com/yv2= XppE

    Had a GigaNews account which was removed for harassing Owl

    Stopped posting from his fretwizzen Google account since shortly after I co= mplained. Seems he lost that too.

    His wife booted Steven to the curb for cheating on her


    =20
    Only site Steven Petruzzellis has pointed to that has ever been available http://web.archive.org/web/20161019062351/http://www.oldneighborhoodrestaur= ant.net/
    https://goo.gl/DMno6J

    Made by the Go Daddy Website builder and is utter crap. Later he denied he = said he was merely taking credit for someone else's work but Steven is the = contact person http://tinyurl.com/hcw6dul http://web.archive.org/web/20161202192456/http://www.reservationdiary.eu/en= g/reservation/d76d1156-e9f7-43c1-b77b-b07189857820

    He also bragged he was working on an update and showed it here https://vid.= me/u6RK

    The business still failed.

    He likely went to the Go Daddy Website Builder after he failed to get WordP= ress installed.

    https://mu.wordpress.org/forums/topic/13879


    This is why Steve "Steven Petruzzellis" Carroll attacks Owl.=20


    Steven Petruzzellis was is divorced because his wife caught him screwing an= other woman.

    Owl is married and by all appearances happily so.=20
    He never complains about his wife in COLA.


    Steven Petruzzellis is living on charity of a friend in a single room.

    Owl does not live in a mansion or even a high end home but has a house and =
    a yard.


    Steven Petruzzellis has two kids but no respect. He repeatedly called Ryan = his "little screwup" and refers to his son Steve as a "dick" and worse. He = says at least one of them likely hacked his computer and is a "mentally def= icient child." He mocks his possible future daughter-in-law as someone who = takes too many selfies and is focused only on herself

    Owl has two kids (or more) and never speaks poorly of them in public.=20
    No reason to think they are not a happy family.


    Steven Petruzzellis claims to be a stay at home dad who pays thousands of d= ollars for day care. Steven has no job and no purpose in life. Steven has g= iven up and now seeks a mother-figure to date.=20

    Owl has his own business doing technical work and also teaches.=20
    Owl offers a true contribution to society.=20
    Teachers are truly under appreciated.

    --
    I Left My Husband & Daughter At Home And THIS happened https://youtu.be/iztSc_msHuo http://www.5z8.info/mydick_x6g9hr_nakedgrandmas.jpg https://groups.google.com/forum/#!topic/comp.os.linux.advocacy/smzXrBhsWf4 Jonas Eklundh Communication AB

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: The Kofo System II BBS (110:300/11@linuxnet)
  • From Steven Petruzzellis@110:300/11 to All on Thu Mar 29 10:22:56 2018
    On Wednesday, March 28, 2018 at 5:32:47 AM UTC-7, Java Jive wrote:
    (was 'Choosing a board for a NAS/SAN/Object storage', and before I say=20 anything else, thanks to J O Aho for his helpful reply there, but I=20
    don't want to hijack that thread, so have started this new one)
    =20
    You will recall that I wrote:
    =20
    I've built my own cross-chain running under
    Ubuntu 16.04 on one of my laptops, but, although this seems to work an=
    d
    can cross-compile simple programmes, such as binutils for example, it cannot cross-compile gcc or glibc, again after a while there is a show stopping error.
    =20
    Here is a typical case in point. This morning I have successfully=20 cross-compiled - by which I mean that the compilation and installation=
    =20
    into the arm sysroot completed successfully, but whether the binaries=20 created will actually run on the arm hardware is yet to be tested -=20
    the following ...
    cups
    curl
    dhcpcd
    expat
    fuse
    libiconv
    openssl
    pcre
    pure-ftpd
    zlib
    =20
    For most of them, all except one I think, the cross-compilation was=20 achieved by giving configure the following parameters ...
    --build=3D${BUILD} --host=3D${HOST}
    ... where ...
    BUILD Describes the build system, Ubuntu 16.04 64-bit
    HOST armv5tejl-unknown-linux-gnueabi
    ... but trying to cross-compile Apache, both versions 2.4.29 and 2.4.33,=
    =20
    with the same configuration parameters, fails with the following:
    =20
    /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libtool --silent=
    =20
    --mode=3Dlink armv5tejl-unknown-linux-gnueabi-gcc -std=3Dgnu99 -g -O2=20
    -o httpd modules.lo buildmark.o -export-dynamic server/libmain.la=20 modules/core/libmod_so.la modules/http/libmod_http.la=20 server/mpm/event/libevent.la os/unix/libos.la -lpcre=20 /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr-util/libaprutil-1=
    ..la=20
    -lexpat -liconv=20 /home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr/libapr-1.la -lrt=
    =20
    -lcrypt -ldl /home/zyxel-nas/NSA-221-GPL/test/arm/xtools/lib/gcc/armv5tejl-unknown-lin=
    ux-gnueabi/4.9.4/../../../../armv5tejl-unknown-linux-gnueabi/bin/ld:=20
    server/mpm/event/.libs/libevent.a(event.o): undefined reference to=20
    symbol 'pthread_sigmask@@GLIBC_2.4' /home/zyxel-nas/NSA-221-GPL/test/arm/sysroot/lib/libpthread.so.0: error=
    =20
    adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/program.mk:22: recipe=
    =20
    for target 'httpd' failed
    make[1]: *** [httpd] Error 1
    make[1]: Leaving directory '/home/zyxel-nas/NSA-221-GPL/test/build/httpd' /home/zyxel-nas/NSA-221-GPL/test/build/httpd/build/rules.mk:75: recipe=20
    for target 'all-recursive' failed
    make: *** [all-recursive] Error 1
    =20
    I have no idea what to make of this. I found nothing on the web that=20 seemed helpful, the sysroot contains GLibC v2.18, not v2.4, and WTF does=
    =20
    'DSO missing from command line' mean in plain English? Something=20
    missing from a command line I can understand, but which command-line and=
    =20
    what is DSO (apart from Digital Switch Over, which doesn't seem likely=20
    to be relevant)!
    =20
    Any suggestions to help me cross-compile Apache would be gratefully=20 received.



    I am working on a program which will show off how weak Xfce is.=20

    Obviously, the sole concern that concerns William 'Super Troll' Unruh is be= ing "honorable", and if he can't have that he will do more research to acti= vely kick "others" down... there is no way to stop him. Taking effort maybe=
    getting informed isn't wasted time. Claiming you know everything and attem= pting to persuade people that it is true, as William 'Super Troll' Unruh tr= ies to do? That is a waste ;)=20



    --=20
    Do not click this link!!
    https://youtu.be/UkAyrfOZaXc
    https://youtu.be/HHT9SJgYsH4
    Jonas Eklundh Communication AB

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: The Kofo System II BBS (110:300/11@linuxnet)
  • From Java Jive@110:300/11 to All on Thu Mar 29 10:30:51 2018
    On 28/03/2018 23:19, Richard Kettlewell wrote:

    The previous error is a better hint: something needs pthread_sigmask but
    no library provides it. AFAIK this is normally resolved automatically
    (shared libraries list their dependencies; perhaps something in the way
    the crossbuild environment is set up has broken this. At any rate the
    answer is probably to add -lpthread.

    This much I've sort of gathered by now, but how? If, say, before
    running configure I do this ...
    export LIBS="${LIBS} -lpthread"
    .... configure fails to complete. If I add it afterwards, there is no
    change, and make fails as above. Exporting CFLAGS or LDFLAGS, or
    setting them in the configure command line, also causes configure to fail.

    For the LIBS test, the details of the failure are as follows:

    checking for working PROCESS_SHARED locks... configure: error: in `/home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr':
    configure: error: cannot run test program while cross compiling
    See `config.log' for more details
    configure failed for srclib/apr

    The relevant part of config.log reads:

    configure:10199: armv5tejl-unknown-linux-gnueabi-gcc -c -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE conftest.c >&5
    conftest.c:52:26: fatal error: minix/config.h: No such file or directory
    #include <minix/config.h>
    ^
    compilation terminated.
    configure:10199: $? = 1
    configure: failed program was:
    | /* confdefs.h */
    | #define PACKAGE_NAME ""
    ....
    | #define HAVE_UNISTD_H 1
    | /* end confdefs.h. */
    | #include <stdio.h>
    | #ifdef HAVE_SYS_TYPES_H
    | # include <sys/types.h>
    | #endif
    ....
    | #include <minix/config.h>
    configure:10199: result: no
    configure:10199: checking minix/config.h presence
    configure:10199: armv5tejl-unknown-linux-gnueabi-gcc -E -DLINUX
    -D_REENTRANT -D_GNU_SOURCE conftest.c
    conftest.c:19:26: fatal error: minix/config.h: No such file or directory
    #include <minix/config.h>
    ^
    compilation terminated.

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (110:300/11@linuxnet)
  • From Richard Kettlewell@110:300/11 to All on Thu Mar 29 11:21:54 2018
    Java Jive <java@evij.com.invalid> writes:
    On 28/03/2018 23:19, Richard Kettlewell wrote:
    The previous error is a better hint: something needs pthread_sigmask but
    no library provides it. AFAIK this is normally resolved automatically
    (shared libraries list their dependencies; perhaps something in the way
    the crossbuild environment is set up has broken this. At any rate the
    answer is probably to add -lpthread.

    This much I've sort of gathered by now, but how? If, say, before
    running configure I do this ...
    export LIBS="${LIBS} -lpthread"
    ... configure fails to complete. If I add it afterwards, there is no
    change, and make fails as above. Exporting CFLAGS or LDFLAGS, or
    setting them in the configure command line, also causes configure to
    fail.

    For the LIBS test, the details of the failure are as follows:

    checking for working PROCESS_SHARED locks... configure: error: in `/home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr':
    configure: error: cannot run test program while cross compiling
    See `config.log' for more details
    configure failed for srclib/apr

    The check is the one in this section: http://svn.apache.org/viewvc/apr/apr/trunk/configure.in?view=markup#l2227

    There is no provision in this code for crossbuilding on threaded
    platforms which have pthread_mutexattr_setpshared. You could add a third argument to AC_TRY_RUN (L2257) to define cross-compile behavior (see the Autoconf documentation for more details).

    The relevant part of config.log reads:

    configure:10199: armv5tejl-unknown-linux-gnueabi-gcc -c -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE conftest.c >&5
    conftest.c:52:26: fatal error: minix/config.h: No such file or directory
    #include <minix/config.h>

    That is not the relevant part.

    --
    https://www.greenend.org.uk/rjk/

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: terraraq NNTP server (110:300/11@linuxnet)
  • From Java Jive@110:300/11 to All on Thu Mar 29 12:56:57 2018
    On 29/03/2018 09:30, Java Jive wrote:

    The relevant part of config.log reads:

    No it doesn't! I must have made the classic error of not reading down
    the file far enough. (It's best to read config.log files from the
    bottom up until the first error, going backwards, is encountered.) The
    actual error is not much more informative that what comes out on the
    console during the running of configure:

    configure:26075: checking for pthread_mutexattr_setpshared
    configure:26075: armv5tejl-unknown-linux-gnueabi-gcc -o conftest -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE conftest.c -lpcre -lexpat -liconv
    -lrt -lcrypt -ldl -lpthread >&5
    configure:26075: $? = 0
    configure:26075: result: yes
    configure:26115: checking for working PROCESS_SHARED locks
    configure:26122: error: in `/home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr':
    configure:26124: error: cannot run test program while cross compiling
    See `config.log' for more details

    Also, you wrote above ...

    On 28/03/2018 23:19, Richard Kettlewell wrote:

    AFAIK this is normally resolved automatically
    (shared libraries list their dependencies; perhaps something in the
    way the crossbuild environment is set up has broken this.

    You could be right, or there might be an even wider problem, because
    I've seen many times before very similar messages to ...
    undefined reference to symbol 'pthread_sigmask@@GLIBC_2.4'
    .... both when cross-compiling, certainly when using my own
    cross-tool-chain and AFAICR also crosstool-ng, but also when compiling
    on the machine itself.

    I think the possibilities are:

    :-( My cross-tool-chain is "close, but no cigar!"
    .... and ...
    :-( So is Zyxel's
    .... or ...
    :-( There is something about this cpu or arm cpus in general that doesn't support threads properly, and this is reflected in the kernel
    config, leading to the errors.

    It may be relevant that I built my cross-tool-chain using Zyxel's kernel source, because it has the necessary OxNAS board configuration files
    (Zyxel NSA221s are built around an OxNAS board). When previously I
    built it using a vanilla download, and tried to boot the resulting
    kernel on the NAS, it appeared to hang at the very beginning, presumably because it couldn't find the serial device to use for console output.
    When I tried to load a kernel built by my toolchain from Zyxel's kernel source, it booted, but baulked when trying to load modules, because the modules in the initrd were a slightly different version - but that was
    fine by me, I was merely trying to prove that my cross-tool-chain had
    produced viable arm code in a viable kernel, and it had.

    In case it's of any help in diagnosing the problems, or of interest or
    use to others who want to try a cross-build, I've copied the relevant
    build scripts up to my website (and renamed them to have *.txt file
    endings, so that they can be downloaded without causing warning messages
    - to run them, they should be renamed back to *.sh, and of course
    have the x-bit set):

    set.sh
    www.macfh.co.uk/Temp/set.sh.txt

    Exports basic variables defining the cross build target; needs a copy of config.guess, for example from the root of a gcc tar, in the same
    directory to set the BUILD variable; 'source'd by all the scripts following.

    build.sh
    www.macfh.co.uk/Temp/build.sh.txt

    Deletes all previous builds for the same CPU, and (re)builds the entire cross-tool-chain from source. You will also need in the same directory
    as build.sh:

    1) A kernel 2.6.24(.4) config file, here's the one I'm using ...
    www.macfh.co.uk/Temp/Zyxel_NSA221-linux-2.6.24.config.txt
    .... and again remove the .txt suffix before use.

    2) a mkimage binary to pack the kernel image into a uImage, but this can
    be commented out if you are not planning to try to load the kernel onto
    an actual device ...
    build.sh: lines 271-3, 494-6

    build.sh takes my dual-core laptop an hour or two, and consumes about
    2-3GB of diskspace. In case it's not obvious, you have to run it
    successfully before you can run ...

    pcre.sh
    www.macfh.co.uk/Temp/pcre.sh.txt

    Cross-builds pcre, a pre-requisite of Apache, and installs it into the
    cross sysroot.

    http2-4.sh
    www.macfh.co.uk/Temp/http2-4.sh.txt

    Attempts to cross-build Apache v2.4, but errors as described.

    These four scripts and their associated files need to be in the same directory, along with the relevant source tars, or links to them if they
    are stored elsewhere. The scripts delete any previously extracted
    sources and attempted builds beneath the directory where they are
    stored, (re)extract the sources into a sub-directory named src, and
    builds in a sub-directory named build. The cross-tools go into a sub-directory name <cpu>/xtools, in this case arm/xtools, and the target
    file system into <cpu>/sysroot, here arm/sysroot.

    Variables defined in the early part of build.sh and httpd2-4.sh
    determine the source tars used, currently these are set to:

    build.sh
    Linux kernel Link to Zyxel source in a different build tree
    GCC v4.9.4 and prerequisites gmp, isl, mpc, mpfr
    GLibC v2.18

    http2-4.sh
    httpd v2.4 and prerequisites apr, apr-util, pcre

    Thus an entire file list would be something like:

    set.sh
    build.sh
    Zyxel_NSA221-linux-2.6.24.config
    (mkimage)
    pcre.sh
    httpd2-4.sh
    config.guess
    linux-2.6.24.tar.bz2
    gcc-4.9.4.tar.bz2
    gmp-6.0.0a.tar.xz
    isl-0.15.tar.bz2
    mpc-1.0.2.tar.gz
    mpfr-3.1.2.tar.bz2
    glibc-2.18.tar.bz2
    ------------------
    pcre-8.41.tar.bz2
    ------------------
    httpd-2.4.33.tar.bz2
    apr-1.6.3.tar.bz2
    apr-util-1.6.1.tar.bz2

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (110:300/11@linuxnet)
  • From Steven Petruzzellis@110:300/11 to All on Thu Mar 29 16:07:12 2018
    On Thursday, March 29, 2018 at 2:21:56 AM UTC-7, Richard Kettlewell wrote:
    Java Jive <java@evij.com.invalid> writes:
    On 28/03/2018 23:19, Richard Kettlewell wrote:
    The previous error is a better hint: something needs pthread_sigmask b=
    ut
    no library provides it. AFAIK this is normally resolved automatically
    (shared libraries list their dependencies; perhaps something in the wa=
    y
    the crossbuild environment is set up has broken this. At any rate the
    answer is probably to add -lpthread.

    This much I've sort of gathered by now, but how? If, say, before
    running configure I do this ...
    export LIBS=3D"${LIBS} -lpthread"
    ... configure fails to complete. If I add it afterwards, there is no change, and make fails as above. Exporting CFLAGS or LDFLAGS, or
    setting them in the configure command line, also causes configure to
    fail.

    For the LIBS test, the details of the failure are as follows:

    checking for working PROCESS_SHARED locks... configure: error: in `/home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr':
    configure: error: cannot run test program while cross compiling
    See `config.log' for more details
    configure failed for srclib/apr
    =20
    The check is the one in this section: http://svn.apache.org/viewvc/apr/apr/trunk/configure.in?view=3Dmarkup#l22=
    27
    =20
    There is no provision in this code for crossbuilding on threaded
    platforms which have pthread_mutexattr_setpshared. You could add a third argument to AC_TRY_RUN (L2257) to define cross-compile behavior (see the Autoconf documentation for more details).
    =20
    The relevant part of config.log reads:

    configure:10199: armv5tejl-unknown-linux-gnueabi-gcc -c -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE conftest.c >&5
    conftest.c:52:26: fatal error: minix/config.h: No such file or director=
    y
    #include <minix/config.h>
    =20
    That is not the relevant part.
    =20
    --=20
    https://www.greenend.org.uk/rjk/



    Nobody gets it, only Tatiana Spearman gets it. Too much glue for you, Gluey= ..=20

    ChromeOS is based on Linux. Of course.=20

    God is trying (with "all they have") to project their modus operandi onto T= atiana Spearman. For over a decade God has spurred the theory that Tatiana = Spearman needs 'witnesses' to point out all his lies. The fact is that nobo=
    dy needs any documentation to do that. So God pulls this absurd circus balo= ney in an incompetent effort to 'hawk' the idea that Tatiana Spearman is li=
    ke him. How God figures out when to use his flood script: http://usenet.san= dman.net/misc/snit_flood. I know we have two different views completely.=20



    --
    E-commerce Simplified
    http://www.macadvocacy.pw/2005/Nov/09/236626.html
    Jonas Eklundh Communication AB

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: The Kofo System II BBS (110:300/11@linuxnet)
  • From Java Jive@110:300/11 to All on Fri Mar 30 13:14:07 2018
    On 29/03/2018 11:56, Java Jive wrote:
    On 29/03/2018 09:30, Java Jive wrote:

    The relevant part of config.log reads:

    No it doesn't!  I must have made the classic error of not reading down
    the file far enough.  (It's best to read config.log files from the
    bottom up until the first error, going backwards, is encountered.)  The actual error is not much more informative that what comes out on the
    console during the running of configure:

    configure:26075: checking for pthread_mutexattr_setpshared
    configure:26075: armv5tejl-unknown-linux-gnueabi-gcc -o conftest -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE  conftest.c -lpcre -lexpat -liconv
    -lrt -lcrypt -ldl -lpthread >&5
    configure:26075: $? = 0
    configure:26075: result: yes
    configure:26115: checking for working PROCESS_SHARED locks
    configure:26122: error: in `/home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr':
    configure:26124: error: cannot run test program while cross compiling
    See `config.log' for more details

    Yes, immediately after I'd finished this rather long post, I received Richard's reply to the same effect as above. I shall investigate his suggestion for a fix more fully later today.

    Also, you wrote above ...

    On 28/03/2018 23:19, Richard Kettlewell wrote:

    AFAIK this is normally resolved automatically
    (shared libraries list their dependencies; perhaps something in the
    way the crossbuild environment is set up has broken this.

    You could be right, or there might be an even wider problem, because
    I've seen many times before very similar messages to ...
        undefined reference to symbol 'pthread_sigmask@@GLIBC_2.4'
    ... both when cross-compiling, certainly when using my own
    cross-tool-chain and AFAICR also crosstool-ng, but also when compiling
    on the machine itself.

    I'm going to try to produce a kernel using crosstool-ng to see if that
    does anything differently.

    I think the possibilities are:

        :-( My cross-tool-chain is "close, but no cigar!"
    ... and ...
        :-( So is Zyxel's
    [quoted out of original order]
    It may be relevant that I built my cross-tool-chain using Zyxel's kernel source, because it has the necessary OxNAS board configuration files
    (Zyxel NSA221s are built around an OxNAS board).  When previously I
    built it using a vanilla download, and tried to boot the resulting
    kernel on the NAS, it appeared to hang at the very beginning, presumably because it couldn't find the serial device to use for console output.
    When I tried to load a kernel built by my toolchain from Zyxel's kernel source, it booted, but baulked when trying to load modules, because the modules in the initrd were a slightly different version  -  but that was fine by me, I was merely trying to prove that my cross-tool-chain had produced viable arm code in a viable kernel, and it had.

    However, despite my concerns above, we know that both produce working
    code. Last night, I tried using my own script to cross-build exactly
    the same version of the kernel as in Zyxel's original builds (so that
    the kernel modules in the initrd would load), loaded it via TFTP, and it booted fully and successfully using Zyxel's original initrd and
    file-system as previously adapted by myself, and in fact is still
    running now.

    ... or ...
    :-( There is something about this cpu or arm cpus in general that doesn't support threads properly, and this is reflected in the kernel config, leading to the errors.

    Jury's still out on that - I have no further information to report.

    In case it's of any help in diagnosing the problems, or of interest or
    use to others who want to try a cross-build, I've copied the relevant
    build scripts up to my website (and renamed them to have *.txt file
    endings, so that they can be downloaded without causing warning messages
     -  to run them, they should be renamed back to *.sh, and of course
    have the x-bit set):

        set.sh
        www.macfh.co.uk/Temp/set.sh.txt

    I've uploaded a new version with tidier source extraction.

    Perhaps I should also have mentioned that the choice of combination of
    version numbers is critical. For example ...

    GLibC:
    v2.4 Doesn't build, can't remember why
    v2.18/9 Both successfully build
    v2.20 Configure error:
    GNU libc requires kernel header files from
    Linux 2.6.32 or later

    Kernel:
    v2.6.24.4 Builds and has OxNAS support
    v2.6.32 Trying to find a version with OxNAS support

    Unfortunately the configuration files for the kernel changed in format
    between the two versions above, so the configuration files of the former cannot be used for the latter without a lot of tedious hand-translation.

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (110:300/11@linuxnet)
  • From Steven Petruzzellis@110:300/11 to All on Fri Mar 30 13:15:52 2018
    On Friday, March 30, 2018 at 4:14:12 AM UTC-7, Java Jive wrote:
    On 29/03/2018 11:56, Java Jive wrote:
    On 29/03/2018 09:30, Java Jive wrote:

    The relevant part of config.log reads:
    =20
    No it doesn't!=C2=A0 I must have made the classic error of not reading =
    down=20
    the file far enough.=C2=A0 (It's best to read config.log files from the=
    =20
    bottom up until the first error, going backwards, is encountered.)=C2=
    =A0 The=20
    actual error is not much more informative that what comes out on the=20 console during the running of configure:
    =20
    configure:26075: checking for pthread_mutexattr_setpshared
    configure:26075: armv5tejl-unknown-linux-gnueabi-gcc -o conftest -g -O2=
    =20
    -DLINUX -D_REENTRANT -D_GNU_SOURCE=C2=A0 conftest.c -lpcre -lexpat -lic=
    onv=20
    -lrt -lcrypt -ldl -lpthread >&5
    configure:26075: $? =3D 0
    configure:26075: result: yes
    configure:26115: checking for working PROCESS_SHARED locks
    configure:26122: error: in=20 `/home/zyxel-nas/NSA-221-GPL/test/build/httpd/srclib/apr':
    configure:26124: error: cannot run test program while cross compiling
    See `config.log' for more details
    =20
    Yes, immediately after I'd finished this rather long post, I received=20 Richard's reply to the same effect as above. I shall investigate his=20 suggestion for a fix more fully later today.
    =20
    Also, you wrote above ...
    =20
    On 28/03/2018 23:19, Richard Kettlewell wrote:

    AFAIK this is normally resolved automatically
    (shared libraries list their dependencies; perhaps something in the
    way the crossbuild environment is set up has broken this.
    =20
    You could be right, or there might be an even wider problem, because=20 I've seen many times before very similar messages to ...
    =C2=A0=C2=A0=C2=A0=C2=A0undefined reference to symbol 'pthread_sigmask=
    @@GLIBC_2.4'
    ... both when cross-compiling, certainly when using my own=20 cross-tool-chain and AFAICR also crosstool-ng, but also when compiling=
    =20
    on the machine itself.
    =20
    I'm going to try to produce a kernel using crosstool-ng to see if that=20 does anything differently.
    =20
    I think the possibilities are:
    =20
    =C2=A0=C2=A0=C2=A0=C2=A0:-( My cross-tool-chain is "close, but no ciga=
    r!"
    ... and ...
    =C2=A0=C2=A0=C2=A0=C2=A0:-( So is Zyxel's
    [quoted out of original order]
    It may be relevant that I built my cross-tool-chain using Zyxel's kerne=
    l=20
    source, because it has the necessary OxNAS board configuration files=20 (Zyxel NSA221s are built around an OxNAS board).=C2=A0 When previously =
    I=20
    built it using a vanilla download, and tried to boot the resulting=20 kernel on the NAS, it appeared to hang at the very beginning, presumabl=
    y=20
    because it couldn't find the serial device to use for console output.=
    =20
    When I tried to load a kernel built by my toolchain from Zyxel's kernel=
    =20
    source, it booted, but baulked when trying to load modules, because the=
    =20
    modules in the initrd were a slightly different version=C2=A0 -=C2=A0 b=
    ut that was=20
    fine by me, I was merely trying to prove that my cross-tool-chain had=
    =20
    produced viable arm code in a viable kernel, and it had.
    =20
    However, despite my concerns above, we know that both produce working=20 code. Last night, I tried using my own script to cross-build exactly=20
    the same version of the kernel as in Zyxel's original builds (so that=20
    the kernel modules in the initrd would load), loaded it via TFTP, and it=
    =20
    booted fully and successfully using Zyxel's original initrd and=20 file-system as previously adapted by myself, and in fact is still=20
    running now.
    =20
    ... or ...
    :-( There is something about this cpu or arm cpus in general that doesn't support threads properly, and this is reflected in the kernel config, leading to the errors.
    =20
    Jury's still out on that - I have no further information to report.
    =20
    In case it's of any help in diagnosing the problems, or of interest or=
    =20
    use to others who want to try a cross-build, I've copied the relevant=
    =20
    build scripts up to my website (and renamed them to have *.txt file=20 endings, so that they can be downloaded without causing warning message=
    s=20
    =C2=A0-=C2=A0 to run them, they should be renamed back to *.sh, and of=
    course=20
    have the x-bit set):
    =20
    =C2=A0=C2=A0=C2=A0=C2=A0set.sh
    =C2=A0=C2=A0=C2=A0=C2=A0www.macfh.co.uk/Temp/set.sh.txt
    =20
    I've uploaded a new version with tidier source extraction.
    =20
    Perhaps I should also have mentioned that the choice of combination of=20 version numbers is critical. For example ...
    =20
    GLibC:
    v2.4 Doesn't build, can't remember why
    v2.18/9 Both successfully build
    v2.20 Configure error:
    GNU libc requires kernel header files from
    Linux 2.6.32 or later
    =20
    Kernel:
    v2.6.24.4 Builds and has OxNAS support
    v2.6.32 Trying to find a version with OxNAS support
    =20
    Unfortunately the configuration files for the kernel changed in format=20 between the two versions above, so the configuration files of the former=
    =20
    cannot be used for the latter without a lot of tedious hand-translation.



    You're like a shark in a goldfish bowl. We all see you hiding there and jus=
    t laugh at you. And you're so brain-dead you keep rejecting it. So what's J= asen Betts's system for the flooding deluge? JavaScript? That is the only l= anguage he knows, or admits to. He must be using it to create these absurd = "flooding" garbage posts. My theory, Jasen Betts took some code that he rev= erse engineered and pretended was his... he is feeding it Autumn Nissen (ht= tps://www.facebook.com/anissen7)'s posts, grabbing random paragraphs, then = altering those using the Viterbi algorithm and then he actively posts them = because his insanity enables him to do that 24/7. I bet we have two differe=
    nt notions about Jasen Betts. After kill filtering all the nyms from Jasen = Betts, it is principally just two flooders posting the vast majority of the=
    bombardment. Crystal clear. And both wholly deranged maniacs.=20

    Many people keep replying to Jasen Betts. I don't blame Autumn Nissen (http= s://www.facebook.com/anissen7) for being annoyed but, in the end, I can not=
    get why he posts here now that he gets what this place is. Autumn Nissen (= https://www.facebook.com/anissen7) is hoping for conversations as experienc=
    ed in a technical forum and open environments simply will never work for hi=
    m. Over and over, the surface request is Jasen Betts wants to "talk tech", = but the guy spends most of his time whining about "obsession". He is undeni= ably lying, he got scared and he's doing the normal BS taught in Trolling 1=
    01 as he moves heaven and earth to regain his pride... but it backfired.=20

    --
    Live on Kickstarter!
    https://youtu.be/UkAyrfOZaXc
    http://www.5z8.info/open.exe_f2s2ea_nazi http://www.5z8.info/hateminorities_t7l3gt_linked-in-of-sex
    Jonas Eklundh Communication AB

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: The Kofo System II BBS (110:300/11@linuxnet)
  • From Java Jive@110:300/11 to All on Fri Mar 30 15:08:25 2018

    On 29/03/2018 10:21, Richard Kettlewell wrote:

    The check is the one in this section: http://svn.apache.org/viewvc/apr/apr/trunk/configure.in?view=markup#l2227

    There is no provision in this code for crossbuilding on threaded
    platforms which have pthread_mutexattr_setpshared. You could add a third argument to AC_TRY_RUN (L2257) to define cross-compile behavior (see the Autoconf documentation for more details).

    Thank you Richard, I'm very grateful, because you've helped
    significantly in finding a solution. However, I would argue that we
    shouldn't be having to traverse this mire together. The Apache team
    should be ensuring their own code cross-compiles without such absurdities.

    In continuation of my argument, the tests that are failing should not
    even be being performed when cross-compiling, as surely they can never
    succeed in running foreign host code on native build hardware, are
    therefore bound to fail, and consequently are spurious. Further, even
    if I could devise something that worked for that particular test, that
    same message occurs in two other places in srclib/apr/configure!

    As I wouldn't know where to begin to write such tests in such a way as
    to make them meaningful - in other words that they succeed in testing foreign host code in the same was as they test native build code - it
    seems easier just to discard the spurious configuration error results,
    and, hey presto, that works!

    http2-4.sh
    www.macfh.co.uk/Temp/http2-4.sh.txt

    New version uploaded which works - it has an export LIBS and a sed
    command to place 'echo' in front of each of those three error aborts in configure.

    So at least I have Apache v2.4 cross-compiling now. However, on further reflection, I think I still have a problem, because the original Zyxel
    builds used v2.2 for their web control and configuration GUI, and I know
    there were some significant backwardly incompatible configuration syntax changes between the two versions, so I shall have to devise some test or
    other to see if their GUI works with 2.4 without modding, because the
    idea of updating all Zyxel's web GUI pages doesn't appeal - it may
    actually be easier to get 2.2 to cross-compile!

    But for now, thank you again for your help.

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (110:300/11@linuxnet)
  • From Richard Kettlewell@110:300/11 to All on Fri Mar 30 18:35:53 2018
    Java Jive <java@evij.com.invalid> writes:
    On 29/03/2018 10:21, Richard Kettlewell wrote:
    The check is the one in this section:
    http://svn.apache.org/viewvc/apr/apr/trunk/configure.in?view=markup#l2227

    There is no provision in this code for crossbuilding on threaded
    platforms which have pthread_mutexattr_setpshared. You could add a third
    argument to AC_TRY_RUN (L2257) to define cross-compile behavior (see the
    Autoconf documentation for more details).

    Thank you Richard, I'm very grateful, because you've helped
    significantly in finding a solution. However, I would argue that we shouldn't be having to traverse this mire together. The Apache team
    should be ensuring their own code cross-compiles without such
    absurdities.

    I donΓÇÖt really see why. Supporting cross-compilation is extra effort,
    the people who care about cross-compilation get to expend that effort
    and (if they so choose) share their changes for inclusion upstream.

    --
    https://www.greenend.org.uk/rjk/

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: terraraq NNTP server (110:300/11@linuxnet)
  • From Steven Petruzzellis@110:300/11 to All on Sat Mar 31 11:09:55 2018
    On Friday, March 30, 2018 at 9:35:55 AM UTC-7, Richard Kettlewell wrote:
    Java Jive <java@evij.com.invalid> writes:
    On 29/03/2018 10:21, Richard Kettlewell wrote:
    The check is the one in this section:
    http://svn.apache.org/viewvc/apr/apr/trunk/configure.in?view=3Dmarkup#=
    l2227

    There is no provision in this code for crossbuilding on threaded
    platforms which have pthread_mutexattr_setpshared. You could add a thi=
    rd
    argument to AC_TRY_RUN (L2257) to define cross-compile behavior (see t=
    he
    Autoconf documentation for more details).

    Thank you Richard, I'm very grateful, because you've helped
    significantly in finding a solution. However, I would argue that we shouldn't be having to traverse this mire together. The Apache team
    should be ensuring their own code cross-compiles without such
    absurdities.
    =20
    I don=E2=80=99t really see why. Supporting cross-compilation is extra eff=
    ort,
    the people who care about cross-compilation get to expend that effort
    and (if they so choose) share their changes for inclusion upstream.
    =20
    --=20
    https://www.greenend.org.uk/rjk/



    The cult-like herd of convenient friends value the LCD in both their lives = and their computer systems.=20

    But when the charts were produced, it turns out with absolute proof, Daniel=
    'The Shill' Lewis was far more "narcissistic" than sms.=20

    All joking aside, those of you who troll are not able to restrain Forth any= more. After yesterday's update I no longer can get work done on Linux. Like=
    anyone can! Daniel 'The Shill' Lewis lies that he uses Windows, while he n= ever recorded it on a modern device and actually tested it. At times, fanta=
    sy is more valuable than facts.=20

    Yup. Unfortunately this is what we have to stop. Trolls who clearly have no=
    reason for being here other than to attack sms.=20



    --=20
    "You'll notice how quickly he loses interest when everything is about him. =
    He clearly wants the attention"
    Steve Carroll, making the dumbest comment ever uttered.

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: The Kofo System II BBS (110:300/11@linuxnet)
  • From Java Jive@110:300/11 to All on Sat Mar 31 12:43:47 2018
    On 30/03/2018 17:35, Richard Kettlewell wrote:

    Thank you Richard, I'm very grateful, because you've helped
    significantly in finding a solution. However, I would argue that we
    shouldn't be having to traverse this mire together. The Apache team
    should be ensuring their own code cross-compiles without such
    absurdities.

    I donΓÇÖt really see why. Supporting cross-compilation is extra effort,
    the people who care about cross-compilation get to expend that effort
    and (if they so choose) share their changes for inclusion upstream.

    The people who write the software, or at least it's 'normal' build
    process, are the people best placed to expend any extra effort required
    to make it cross-compile, because they already know the build code. For anyone else to have to do it means hours of extra effort for a one-off
    job that, hopefully, will not have to be repeated. Which is better
    overall for the world, one team does the job thoroughly once, or that
    one team does half-a-job, and expects half the users of its software to complete it for them, every time they try to install it on a different platform?

    It's as if I were to put up a web-page on my site that only works in
    Internet Explorer, and crashes in other browsers. The whole point of my putting up a web page is to provide something of use to people, so why
    would I want to supply something that is only useful to half the people
    it could potentially benefit? People have produced such web-pages in
    the past, but most probably today you wouldn't get many visitors to
    them! I test my own site in a number of the most commonly used
    browsers, and IMO anyone producing a Linux application should have the
    same sort of intention to make their work as universally applicable as reasonably possible.

    AIUI, the whole point of Linux is to supply a free open-source platform
    to work (roughly) the same across a wide range of devices. Many,
    perhaps even most, of these devices are controlled by a web GUI, but
    also are too strapped for resources to support on-device compilation comfortably, if at all. In such circumstances, for probably the most
    widely used web-server in the world to fail to support cross-compilation
    OOTB is absurd, and maddeningly frustrating for the victims of it.

    But, anyway, thanks again for all your help.

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (110:300/11@linuxnet)
  • From Steven Petruzzellis@110:300/11 to All on Sat Mar 31 13:46:06 2018
    On Saturday, March 31, 2018 at 3:43:52 AM UTC-7, Java Jive wrote:
    On 30/03/2018 17:35, Richard Kettlewell wrote:

    Thank you Richard, I'm very grateful, because you've helped
    significantly in finding a solution. However, I would argue that we
    shouldn't be having to traverse this mire together. The Apache team
    should be ensuring their own code cross-compiles without such
    absurdities.

    I don=E2=80=99t really see why. Supporting cross-compilation is extra e=
    ffort,
    the people who care about cross-compilation get to expend that effort
    and (if they so choose) share their changes for inclusion upstream.
    =20
    The people who write the software, or at least it's 'normal' build=20 process, are the people best placed to expend any extra effort required=
    =20
    to make it cross-compile, because they already know the build code. For=
    =20
    anyone else to have to do it means hours of extra effort for a one-off=20
    job that, hopefully, will not have to be repeated. Which is better=20 overall for the world, one team does the job thoroughly once, or that=20
    one team does half-a-job, and expects half the users of its software to=
    =20
    complete it for them, every time they try to install it on a different=20 platform?
    =20
    It's as if I were to put up a web-page on my site that only works in=20 Internet Explorer, and crashes in other browsers. The whole point of my=
    =20
    putting up a web page is to provide something of use to people, so why=20 would I want to supply something that is only useful to half the people=
    =20
    it could potentially benefit? People have produced such web-pages in=20
    the past, but most probably today you wouldn't get many visitors to=20
    them! I test my own site in a number of the most commonly used=20
    browsers, and IMO anyone producing a Linux application should have the=20 same sort of intention to make their work as universally applicable as=20 reasonably possible.
    =20
    AIUI, the whole point of Linux is to supply a free open-source platform=
    =20
    to work (roughly) the same across a wide range of devices. Many,=20
    perhaps even most, of these devices are controlled by a web GUI, but=20
    also are too strapped for resources to support on-device compilation=20 comfortably, if at all. In such circumstances, for probably the most=20 widely used web-server in the world to fail to support cross-compilation=
    =20
    OOTB is absurd, and maddeningly frustrating for the victims of it.
    =20
    But, anyway, thanks again for all your help.



    Jesus 'The Fool' Christ and Manfred both lie constantly and flagrantly and = continue to do so. So no motivation in showing any further kindness or judi= ciousness. Jesus 'The Fool' Christ asked to be rated according to direct st= atistical evidence, which I accommodated. Over and over, the demand is he w= ants to "talk tech", but Jesus 'The Fool' Christ spends most of his time wh= ining about "trolling". A shadow of causation, projected perfectly, at the = wrong time.=20

    The cult-like herd of convenient friends value being like everyone else in = both their lives and their computer systems.=20

    It should not matter because the FROM line on a post does not matter, it's = the content that counts.=20

    This forum is a cesspool.=20



    --=20
    Live on Kickstarter! https://groups.google.com/forum/#!topic/alt.os.linux/BVpdH5KOc6s
    Jonas Eklundh Communication AB

    --- MBSE BBS v1.0.7.2 (GNU/Linux-x86_64)
    * Origin: The Kofo System II BBS (110:300/11@linuxnet)