Getting kille72 to build -- bugs galore

Discussion in 'Tomato Firmware' started by koitsu, Apr 6, 2018.

  1. koitsu

    koitsu Network Guru Member

    While doing something unrelated, I at least wanted to test my code so I built a fresh VM and did my best to get ARM to build. I've done this before (for both MIPS and ARM, obviously) -- but on Toastman branches, and thus not anything relating to Shibby MultiWAN.

    Yeah... wow. It's now almost 3 in the morning. What a nightmare. I was successful, but I wanted to document the absolute mayhem I went through.

    I started with Linux Mint 17.3 Cinnamon 64-bit.

    First issue: flac wouldn't build due to makeinfo not being available. Rectified this by installing texinfo package. Lesson: README.md in the repository should really document what OSes can successfully build the firmware (be sure to include 32-bit (i386) vs. 64-bit (amd64)), and what packages are needed.

    Second issue: flac still wouldn't build, this time due to claims that aclocal-1.15 wasn't present on my system. Initially this made no sense. aclocal is part of automake, and while automake 1.14 + automake 1.11 + automake 1.9 were all on my system, 1.15 was not. Mint 17.3 also has no automake 1.15 package, so where was this coming from? This really smelled of a "weird packaging problem", which also bothered me because I have instructions privately from Toastman a while ago talking about how 17.3 works fine -- but I was trying 64-bit remember. Rather than fight with autotools, I decided to switch OSes and start over. The errors I saw, BTW:

    Code:
    touch flac/stamp-h1
    make[5]: Entering directory `/home/jdc/tomato-arm-kille72/release/src-rt-6.x.4708/router/flac/src/libFLAC'
    cd ../.. && make  am--refresh
    make[6]: Entering directory `/home/jdc/tomato-arm-kille72/release/src-rt-6.x.4708/router/flac'
    CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/jdc/tomato-arm-kille72/release/src-rt-6.x.4708/router/flac/missing aclocal-1.15 -I m4
    /home/jdc/tomato-arm-kille72/release/src-rt-6.x.4708/router/flac/missing: line 81: aclocal-1.15: command not found
    WARNING: 'aclocal-1.15' is missing on your system.
             You should only need it if you modified 'acinclude.m4' or
             'configure.ac' or m4 files included by 'configure.ac'.
             The 'aclocal' program is part of the GNU Automake package:
             <http://www.gnu.org/software/automake>
             It also requires GNU Autoconf, GNU m4 and Perl in order to run:
             <http://www.gnu.org/software/autoconf>
             <http://www.gnu.org/software/m4/>
             <http://www.perl.org/>
    make[6]: *** [aclocal.m4] Error 127
    
    Third issue: I then tried Linux Mint 18.3 Cinnamon 64-bit and Ubuntu 14.04.5 LTS 64-bit. Both OSes couldn't run the toolchain binaries (which are i386 binaries that build binaries/results for ARM), citing missing 32-bit shared libraries like libelf.so.1, libz.so.{iforget}, and libmpc.so.2, amongst others; ldd on the toolchain binaries confirmed this. I couldn't remember how to rebuild the toolchain (note: if someone remembers, please remind me). I tinkered a bit with this and managed to get libelf and libz working (right versions, though? Don't know!) by doing apt-get install {whatever}:i386, but libmpc was too old (only libmpc.so.3 was available). I'd mentioned in the past -- on my own blog -- that you really had to build TomatoUSB on a 32-bit OS to avoid dealing with 32-bit compatibility shims/libs on a 64-bit OS, but I knew some people got this working. Anyway, this wasted several hours.

    I gave up and switched to a 32-bit OS: Ubuntu 14.04.5 LTS 32-bit. This actually worked -- that is to say, the toolchain binaries ran without any trouble, but lo and behold.....

    Fourth issue: re-encountered the problem described in Second issue. Two OSes, different archs, both complaining about aclocal-1.15 crap with flac? This has to be something closer to home. What this also meant, BTW, was that Linux Mint 17.3 64-bit might actually be OK to use, but I'm not 100% sure. I haven't had time to go back and re-try it. Anyway, back to flac and aclocal:

    After digging through autotools scripts and other madness, I determined that for some reason the tools were doing something stupid and picking version 1.15 arbitrarily. flac/autogen.sh has this hard-coded but only if uname -s returns OpenBSD (it doesn't; it returns Linux). This was driving me literally mad. But then an obvious thing hit me: was autoreconf being called before building flac?

    router/Makefile:
    Code:
    flac/stamp-h1: libogg
            cd flac && \
            CFLAGS="-Os $(EXTRACFLAGS) -fPIC -ffunction-sections -fdata-sections" \
            CPPFLAGS="-I$(TOP)/libogg/include -I$(LINUXDIR)/include" \
            LDFLAGS="-L$(TOP)/libogg/src/.libs -fPIC -ffunction-sections -fdata-sections -Wl,--gc-sections" \
            $(CONFIGURE) --enable-shared --enable-static --prefix='' --disable-rpath \
                    --disable-doxygen-docs --disable-xmms-plugin --disable-cpplibs \
                    --without-libiconv-prefix --disable-altivec --disable-3dnow --disable-sse
            touch flac/stamp-h1
    
    flac: flac/stamp-h1 libogg
            @$(MAKE) -C flac/src/libFLAC all $(PARALLEL_BUILD)
    
    Nope. Sigh. The fix: use autoreconf -fsi appropriately:

    Code:
    flac/stamp-h1: libogg
            cd flac && \
            autoreconf -fsi && \
            CFLAGS="-Os $(EXTRACFLAGS) -fPIC -ffunction-sections -fdata-sections" \
            CPPFLAGS="-I$(TOP)/libogg/include -I$(LINUXDIR)/include" \
            LDFLAGS="-L$(TOP)/libogg/src/.libs -fPIC -ffunction-sections -fdata-sections -Wl,--gc-sections" \
            $(CONFIGURE) --enable-shared --enable-static --prefix='' --disable-rpath \
            ...
    
    I have no idea how no one has seen this until now. Is everyone running development builds of Ubuntu or something (where automake 1.15 is the default, I believe)? Bizarre.

    We got much further this time, but not all the way.

    Fifth issue: minidlna would not build, citing config.h didn't exist. True? Better check:

    Code:
    make[6]: Leaving directory `/home/jdc/tomato-arm-kille72/release/src-rt-6.x.4708/router/libvorbis/lib'
    make[5]: Leaving directory `/home/jdc/tomato-arm-kille72/release/src-rt-6.x.4708/router/libvorbis/lib'
       minidlna
    make[5]: Entering directory `/home/jdc/tomato-arm-kille72/release/src-rt-6.x.4708/router/minidlna'
    arm-brcm-linux-uclibcgnueabi-gcc -DBCMWPA2 -DBCMQOS -DBCM_DCS -DEXT_ACS -DD11AC_IOTYPES -DNAS_GTK_PER_STA -DPHYMON -DPROXYARP -DTRAFFIC_MGMT -DTRAFFIC_MGMT_RSSI_POLICY -DLINUX26 -DCONFIG_BCMWL5 -DCONFIG_BCMWL6 -DCONFIG_BCMWL6A -DPART_JFFS2_GAP=0UL -pipe -fno-strict-aliasing -DBCMWPA2 -DBCMARM -marm  -DTCONFIG_NVRAM_64K -DLINUX_KERNEL_VERSION=132644 -O2 -D__CONFIG_EMF__    minidlna.c   -o minidlna
    minidlna.c:72:20: fatal error: config.h: No such file or directory
    
    ...
    
    jdc@tomato-build:~/tomato-arm-kille72/release/src-rt-6.x.4708$ ls -l router/minidlna/
    total 1808
    ...
    -rwxrwxr-x 1 jdc jdc  42856 Apr  5 22:54 config.guess
    -rw-rw-r-- 1 jdc jdc  14812 Apr  5 22:54 config.h.in
    -rw-rw-r-- 1 jdc jdc  14745 Apr  5 22:54 config.h.in~
    -rwxrwxr-x 1 jdc jdc  18442 Apr  5 22:54 config.rpath
    -rwxrwxr-x 1 jdc jdc  35837 Apr  5 22:54 config.sub
    -rwxrwxr-x 1 jdc jdc 359608 Apr  5 22:54 configure
    -rw-rw-r-- 1 jdc jdc  22028 Apr  5 22:54 configure.ac
    -rw-rw-r-- 1 jdc jdc   5985 Apr  5 22:54 containers.c
    -rw-rw-r-- 1 jdc jdc   1179 Apr  5 22:54 containers.h
    -rw-rw-r-- 1 jdc jdc  18420 Apr  5 22:54 COPYING
    ...
    
    Sigh. Better look at the minidlna target:

    Code:
    minidlna: zlib sqlite ffmpeg libogg flac jpeg libexif libid3tag libvorbis
            @$(SEP)
            $(call patch_files,minidlna)
            @$(MAKE) -C minidlna CC=$(CC) $(if $(MEDIA_SERVER_STATIC),STATIC=1,) minidlna $(PARALLEL_BUILD)
    
    minidlna-clean:
            -@$(MAKE) -C minidlna clean
            @rm -f minidlna/stamp-h1
            $(call unpatch_files,minidlna)
    
    Why is $(call) being used? What is patch_files? Wait. Oh no. Please no. Please tell me there isn't embedded shell code in router/Makefile...

    Code:
    define patch_files =
     find patches/$(1) -maxdepth 1 -type f -name '*.patch' | sort -t '\0' -n | while read FILE; do \
      ( if ! patch -p0 -Rf --dry-run --silent < $$FILE 2>/dev/null; then \
       patch -p0 < $$FILE; \
      fi ) \
     done
    endef
    
    define unpatch_files =
     find patches/$(1) -maxdepth 1 -type f -name '*.patch' | sort -t '\0' -n | while read FILE; do \
      ( if patch -p0 -Rf --dry-run --silent < $$FILE 2>/dev/null; then \
       patch -p0 -Rf < $$FILE; \
      fi ) \
     done
    endef
    
    Reference: https://www.gnu.org/software/make/manual/html_node/Call-Function.html

    Dramatic but true: I almost began to cry. *hangs head* This just reminds me of the utter madness that is the FreeBSD Ports framework. Do not look at this if you value your sanity; especially avoid this one. I spent literally months trying to comprehend that mess, and I wasn't going to revisit it. Makefiles are not well-suited for embedded shell; you either have to use native make functions or rely on a callout to an actual program or script to get what you need (and the latter is risky when used in parallel anyway).

    I verified that my system clock was correct and that chrony was running + clock drift was not happening (make does horrible things if the clock drifts). I then sifted through make -d output, which is something I haven't had to do in maybe 10 years. If you've never done this, well... Dante never envisioned this 11th layer of hell. make -d surprisingly didn't indicate any shell invocations around the minidlna target. I had the output, but the file was literally 200MBytes, so just trust me. I verified this was the case by adding some echo statements in the above functions -- nada.

    I checked for patches/minidlna and sure enough there's a nice large on that contains the raw config.h and many other files:

    Code:
    jdc@tomato-build:~/tomato-arm-kille72/release/src-rt-6.x.4708/router$ grep -c '^+++' patches/minidlna/101-tomato-specific.patch
    21
    
    I tracked down who introduced this $(call) madness (hi pedro!), said screw that (though agree a "general solution" should have been implemented), and wrote what should be used for cases like this: a pair of very simple helper shell scripts (one for application of patches (apply), one for reversing of patches (unapply) -- these basically do the same as the above), and then replaced things as such:

    Code:
    minidlna: zlib sqlite ffmpeg libogg flac jpeg libexif libid3tag libvorbis
            @$(SEP)
            @$(TOP)/patches/apply minidlna
            @$(MAKE) -C minidlna CC=$(CC) $(if $(MEDIA_SERVER_STATIC),STATIC=1,) minidlna $(PARALLEL_BUILD)
    
    minidlna-clean:
            -@$(MAKE) -C minidlna clean
            @rm -f minidlna/stamp-h1
            @$(TOP)/patches/unapply minidlna
    
    Lo and behold... everything worked. I then replaced all the $(call) occurrences appropriately... and everything mostly worked. I learned that there were several $(call)s to apply patches from directories in patches/ that didn't exist (i.e. miniupnpd, nano, and ipset). Bad housekeeping on someone's part. :) So I removed those where appropriate.

    Result: ac68e target firmwares that built:

    Code:
    jdc@tomato-build:~/tomato-arm-kille72/release/src-rt-6.x.4708$ ls -l image/
    total 35064
    -rw-rw-r-- 1 jdc jdc 11968512 Apr  6 02:49 tomato-RT-AC56U-ARM-2018.1-VPN-64K.trx
    -rw-rw-r-- 1 jdc jdc 11968512 Apr  6 02:49 tomato-RT-AC68U-ARM-2018.1-VPN-64K.trx
    -rw-rw-r-- 1 jdc jdc 11968512 Apr  6 02:49 tomato-RT-N18U-ARM-2018.1-VPN-64K.trx
    
    Odds are other targets might not build due to missing packages and so on, but considering I hacked on this for almost 7 hours, I'm content.

    I plan on making branches/pull requests for these problems separately so that they can be discussed and/or merged.

    P.S. -- Thanks to pedro who got rid of the V1/V2 argument madness. On the other hand, same fellow introduced the $(call) stuff, but eh... ;-)
     
    Last edited: Apr 6, 2018
  2. Magister

    Magister LI Guru Member

    Thanks for the heads up! I built my own Tomato based on Toastman for my E3000 for years, yes on Mint various version 32 bits but also on LMDE2 64 bits, I remember the setup to have the correct lib/tools was difficult! I never tried the ARM branch but now I have switched router, I should check out the repo and try...
     
  3. AndreDVJ

    AndreDVJ LI Guru Member

    minidlna needs some serious thought on that patch file. I only wanted to upgrade minidlna, not to sanitize its build system, for my own sanity. There's stuff left to do. Looking at the patch file it seems pretty obvious that genconfig.sh and config.h look redundant. Sanitizing how stuff in TomatoUSB works is an utter nightmare.

    The real thing is to keep busybox up to date. It's not worth of anyone's time I'm sure of that.

    EDIT: Got rid of genconfig.sh - the line that was calling this script was always commented out.
    https://bitbucket.org/AndreDVJ/advancedtomato-arm/commits/c08b82aa5d99873a2bfab9cd3ea9f20e3f83a511
     
    Last edited: Apr 7, 2018
  4. pedro311

    pedro311 Networkin' Nut Member

    Building a VPN version is easy, I'm wondering what difficulties you will have with AIO :p ;)
    BTW, there are no such problems on Debian 9.2.1 (@kille72 also compiling on Debian).
     
  5. kille72

    kille72 LI Guru Member

    Correctly, I'm using Debian 9.4 without any problems ;)
     
  6. M_ars

    M_ars Network Guru Member


    Hi koitsu,
    thx for that topic and description. I have a working build environment for Toastman ARM & MIPS running on Mint 17.3 x64
    Yesterday i tried to build kille72 (only VPN build) and ran into the exact same problems you are describing

    I had to make a break at the minidlna-patch. This is where it stops right now...
    config.h and some other files are not in place and the patch does not work? I will have a look at that tonight

    Can/Could you provide a patch for the "second issue" (autoreconf -fsi) for Kille72-branch? and hopefully kille72 will add it? :)
    I think there is not much missing to make it work with Mint 17.3 64 bit
     
  7. koitsu

    koitsu Network Guru Member

    flac build fix (autoreconf needed): https://bitbucket.org/koitsu2018/tomato-arm-kille72/commits/ba000540781f8c23b8b4ace420c509e6e1dde48f

    General patching rework; this should fix minidlna building (regardless of AndreDVJ's updated patch file or not): https://bitbucket.org/koitsu2018/tomato-arm-kille72/commits/6e9613cda47a694ed6c74b75eeaa396a1bbcc62a

    If you want you can also download AndreDVJ's updated router/patches/minidlna/101-tomato-specific.patch file and drop it into that directory (replace the existing file) and it should still build (I tested it earlier tonight). You can wget it directly: https://bitbucket.org/AndreDVJ/adva...er/patches/minidlna/101-tomato-specific.patch

    Debian 9.2 or 9.4 -- how nice nobody specified i386 or amd64. Come on guys, you read my long explanation about architecture behavioural differences and neither disclose arch? :p Debian building things "just fine" doesn't change that these are real/confirmed problems, and we see people on the forum show up talking about them as well. Some part of the GNU autotools (automake, autoconf, etc.) or GNU make may be behaving differently on Debian (it may be the same version but have unique patches for bugs), I simply don't know. The GNU autotools are notorious for being finicky and break in very odd ways (this isn't a new -- autoconf in particular is the worst offender). For some things you should use the included configure script (if it comes with the software), for other things autoreconf has to be run, and for others a specific version of autoconf or automake has to be used.

    What OS version and architecture kille72 builds his firmware on should be clearly disclosed in README.md, along with all the pre-requisite package names (re: apt-get install) for that OS version. These "build frustrations" plagued Tomato since the beginning -- it's almost tribal knowledge at this point. I have notes, PMs, and all sorts of nonsense, plus the old blog post of mine for MIPS.

    And yeah, AIO probably won't build due to missing pre-req packages. I could probably figure that out one night, but since I don't use AIO...... ;)
     
    kille72 likes this.
  8. kille72

    kille72 LI Guru Member

    Sorry, x64.
     
  9. maurer

    maurer Network Guru Member

    I believe there are more armel/hf debian installations out there than i386 currently.
    does anyone builds tomato on i386? I don't think so...
    so unless stated otherwise x64 is the implicit architecture these days

    and back on topic - I also use debian (x64 - of course) and have none of the issues above
     
    kille72 likes this.
  10. kille72

    kille72 LI Guru Member

    Debian 9.4 - x64, if I remember correctly, I created the environment like this:

    1. install base packages with all depends
    sudo apt-get update

    sudo apt-get install build-essential autoconf m4 bison flex g++ libtool sqlite gcc g++ binutils patch bzip2 make gettext unzip zlib1g-dev libc6 gperf sudo automake groff
    sudo apt-get install lib32stdc++6 libncurses5 libncurses5-dev gawk gitk zlib1g-dev autopoint shtool autogen mtd-utils gcc-multilib gconf-editor lib32z1-dev pkg-config libssl-dev automake
    sudo apt-get install libxml2-dev intltool libglib2.0-dev libstdc++5 texinfo dos2unix xsltproc libnfnetlink0 libcurl4-openssl-dev libxml2-dev libgtk2.0-dev libnotify-dev libevent-dev mc git
    sudo apt-get install texlive

    2. remove it if installed. It stopped PHP compilation.
    sudo apt-get remove libicu-dev

    3. install i386 elf1 packages
    sudo dpkg --add-architecture i386
    sudo apt-get install libelf1

    4. if version of installed bison is 3.0 or higher you have to install older one (this may not be necessary with PHP 7.x)
    sudo apt-get remove bison libbison-dev

    wget http://launchpadlibrarian.net/140087283/libbison-dev_2.7.1.dfsg-1_amd64.deb
    wget http://launchpadlibrarian.net/140087282/bison_2.7.1.dfsg-1_amd64.deb
    sudo dpkg -i libbison-dev_2.7.1.dfsg-1_amd64.deb
    sudo dpkg -i bison_2.7.1.dfsg-1_amd64.deb
    sudo apt-mark hold libbison-dev bison

    5. sudo apt-get install libelf1 libelf-dev:i386 libelf1:i386
    sudo updatedb

    6. clone/download repository

    7. edit profile file and add toolchain directories to your path

    8. reboot your system

    Code:
    $ sudo apt show automake
    Package: automake
    Version: 1:1.15-6
    Priority: optional
    Section: devel
    Source: automake-1.15
    Maintainer: Eric Dorland <eric@debian.org>
    Installed-Size: 1,748 kB
    Depends: autoconf (>= 2.65), autotools-dev (>= 20020320.1)
    
    $ sudo apt show libtool
    Package: libtool
    Version: 2.4.6-2
    Priority: optional
    Section: devel
    Maintainer: Kurt Roeckx <kurt@roeckx.be>
    Installed-Size: 1,257 kB
    Depends: gcc | c-compiler, cpp, libc6-dev | libc-dev, file, autotools-dev
    
    $ sudo apt show pkg-config
    Package: pkg-config
    Version: 0.29-4+b1
    Priority: optional
    Section: devel
    Source: pkg-config (0.29-4)
    Maintainer: Tollef Fog Heen <tfheen@debian.org>
    Installed-Size: 193 kB
    Depends: libc6 (>= 2.14), libglib2.0-0 (>= 2.16.0), libdpkg-perl
    
    $ sudo apt show bison
    Package: bison
    Version: 2:3.0.4.dfsg-1+b1
    Priority: optional
    Section: devel
    Source: bison (2:3.0.4.dfsg-1)
    Maintainer: Chuan-kai Lin <cklin@debian.org>
    Installed-Size: 2,110 kB
    Depends: m4, libc6 (>= 2.15), libbison-dev (= 2:3.0.4.dfsg-1+b1)
    
    $ sudo apt show libbison-dev
    Package: libbison-dev
    Version: 2:3.0.4.dfsg-1+b1
    Priority: optional
    Section: libdevel
    Source: bison (2:3.0.4.dfsg-1)
    Maintainer: Chuan-kai Lin <cklin@debian.org>
    Installed-Size: 449 kB
    
     
    Last edited: Apr 7, 2018
    koitsu, pedro311 and pomidor1 like this.
  11. M_ars

    M_ars Network Guru Member

    WORKING with Mint 17.3 x64 cinnamon :)

    Thank you very much
    -->the two pachtes do make it possible

    @kille72 would it be possible to add those two patches to your main-branch? I know that there are no problems with Debian 9.2 or 9.4, but I think it is a good thing to make it also work with Mint 17.3 :D

    best regrads
    M_ars
     
  12. kille72

    kille72 LI Guru Member

    Ok.
    Code:
    git clone https://bitbucket.org/kille72/tomato-arm-kille72.git
    and test it on Mint 17.3-x64 :)
     
    M_ars likes this.
  13. Sean B.

    Sean B. LI Guru Member

    Is the path addition different than what I'm used to? IE:

    Code:
    sudo ln -s /home/sean/git/tomato-arm-kille72/release/src-rt-6.x.4708/toolchains/hndtools-arm-linux-2.6.36-uclibc-4.5.3 /opt/brcm-arm
    export PATH="${PATH}:/opt/brcm-arm/bin"
     
  14. koitsu

    koitsu Network Guru Member

    Path is the same, Sean.
     
  15. M_ars

    M_ars Network Guru Member

    Hi kille72,

    did clone your branch including latest patches (cleanup minidlna patch... up to Fix flac building)

    Everything is working perfect but it stops at mindlna

    Code:
    make[5]: Verzeichnis »/home/mars/tomato/release/src-rt-6.x.4708/router/minidlna« wird betreten
    arm-brcm-linux-uclibcgnueabi-gcc -DBCMWPA2 -DBCMQOS -DBCM_DCS -DEXT_ACS -DD11AC_IOTYPES -DNAS_GTK_PER_STA -DPHYMON -DPROXYARP -DTRAFFIC_MGMT -DTRAFFIC_MGMT_RSSI_POLICY -DLINUX26 -DCONFIG_BCMWL5 -DCONFIG_BCMWL6 -DCONFIG_BCMWL6A -DPART_JFFS2_GAP=0UL -pipe -fno-strict-aliasing -DBCMWPA2 -DBCMARM -marm  -DTCONFIG_NVRAM_64K -DLINUX_KERNEL_VERSION=132644 -O2 -D__CONFIG_EMF__    minidlna.c   -o minidlna
    minidlna.c:72:20: fatal error: config.h: Datei oder Verzeichnis nicht gefunden
    compilation terminated.
    make[5]: *** [minidlna] Fehler 1
    
    ==> short translation to english:
    minidlna.c:72:20: fatal error: config.h: file not found


    If i then apply the patch (with helper shell scripts to apply and unapply) from koitsu, everything is working (--> no further changes)
    https://bitbucket.org/koitsu2018/tomato-arm-kille72/commits/6e9613cda47a694ed6c74b75eeaa396a1bbcc62a
    and Mint17.3x64 is able to build tomato by kille72 :cool:


    Code:
    $(call patch_files,minidlna) ==> can not get it to work with Mint (do not know why...)
    
    and the other way
    
    @$(TOP)/patches/apply minidlna ==> works every time, reproduce able
    
    Could you try if this patch / way would also work for your tomato build environment / setup? :)
    (if yes - could you add the patch also to your main branch?)
     
  16. kille72

    kille72 LI Guru Member

  17. M_ars

    M_ars Network Guru Member


    I can confirm, that VPN-Builds are working (only with both patches). I have not tried AIO builds :)
    I guess it will not work right now because of some missing packages --> I will check tomorrow and see what happens

    But still - I think it is a good thing, that it is possible to build at least the vpn build with mint 17.3x64
     
  18. tvlz

    tvlz LI Guru Member

    Removing the "=" sign should make make it work, the "=" prevents it from patching, at least on my MIPS RT-N build Mint 17.3-x64
    Code:
    define patch_files =
    define unpatch_files =
    to
    define patch_files
    define unpatch_files
    
     
  19. Sean B.

    Sean B. LI Guru Member

    I'm guessing this is some sort of package conflict on my build system, but haven't had time to look into it yet. Mint 17.3

    Code:
     [rc] CC pbr.o
     [rc] CC usb.o
     [rc] CC ddns.o
     [rc] CC cifs.o
     [rc] CC jffs2.o
     [rc] CC vpn.o
     [rc] CC pptpd.o
     [rc] CC pptp_client.o
    pptp_client.c: In function ‘pptp_client_table_add’:
    pptp_client.c:457:5: warning: implicit declaration of function ‘get_cidr’
     [rc] CC snmp.o
     [rc] CC rc
       text       data        bss        dec        hex    filename
     322795       1360      12080     336235      5216b    rc
    make[5]: Leaving directory `/home/sean/git/tomato-arm-kille72/release/src-rt-6.x.4708/router/rc'
    ( cd iptables-1.4.x ; ./autogen.sh )
    libtoolize: putting auxiliary files in `.'.
    libtoolize: copying file `./ltmain.sh'
    libtoolize: `/usr/share/aclocal/libtool.m4' does not exist.
    autoreconf: libtoolize failed with exit status: 1
    make[4]: *** [iptables-1.4.x/configure] Error 1
    make[4]: Leaving directory `/home/sean/git/tomato-arm-kille72/release/src-rt-6.x.4708/router'
    make[3]: *** [all] Error 2
    make[3]: Leaving directory `/home/sean/git/tomato-arm-kille72/release/src-rt-6.x.4708'
    make[2]: *** [bin] Error 2
    make[2]: Leaving directory `/home/sean/git/tomato-arm-kille72/release/src-rt-6.x.4708'
    make[1]: *** [e] Error 2
    make[1]: Leaving directory `/home/sean/git/tomato-arm-kille72/release/src-rt-6.x.4708'
    make: *** [ac68e] Error 2
    sean@MintBox ~/git/tomato-arm-kille72/release/src-rt-6.x.4708 $
    **EDIT**

    Yup, sure enough. Had a libtool package installed that it didn't appreciate.
     
  20. koitsu

    koitsu Network Guru Member

    I don't think this is true at all. The GNU make manual is quite clear about the difference between define with and without an equals operator: there is none. "The define directive is followed on the same line by the name of the variable being defined and an (optional) assignment operator ..... You may omit the variable assignment operator if you prefer. If omitted, make assumes it to be '=' ...". Reference: https://www.gnu.org/software/make/manual/html_node/Multi_002dLine.html#Multi_002dLine . If someone can track down how GNU make on Debian differs with regards to this behaviour/problem compared to other distros (Ubuntu, Mint) and provide an actual link to that, I'd love to read it.

    Fact of the matter is, the $(call) line wasn't even executing anything per make -d. How/why that would happen (when some other recipes and targets did so just fine) is unknown -- probably some very uncomfortable bug with GNU make. Doesn't surprise me.

    My general experience with make (both non-GNU and GNU) is that more often than not, "weird problems" crop up when involving shell -- it's always better to use purely native make functions/-isms, and more often than not, that can't be done 100% natively. As such, I urge folks working on this branch to please stop shoving shell into Makefiles. There's generally no gain from it and the risks tend to be high, plus syntactically becomes a nightmare. I know this is hard to swallow, but I've been doing this a long time...
     
  21. M_ars

    M_ars Network Guru Member

    i tried that, thx for the hint --> since it should not make any difference the optional assignment operator "=" ??
    BUT it works so far...very strange. Did test/check it three times

    --> VPN targets are working
    --> AIO stops right now at mysql, same problem/error like here
    http://www.linksysinfo.org/index.php?threads/compilation-error-for-mysql.71247/
     
    tvlz likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice