<mangix>
ah jffs2 is y2038 compliant but not y2106 compliant
<mangix>
same with squashfs
Tapper has quit [Ping timeout: 480 seconds]
GNUmoon has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
minimal has joined #openwrt-devel
<neggles>
mangix: I would like to hope that 80 years from now squashfs and jffs2 will be quite dead... but probably we'll just end up with jffs3 :P
danitool has quit [Ping timeout: 480 seconds]
<mangix>
neggles: I hope not. maybe f2fs is an acceptable replacement for jffs2
<mangix>
the issue is a second stage bootloader would have to be implemented for that.
<neggles>
mangix: or self-managed flash
<neggles>
80 years is a long time...
<mangix>
neggles: well. my understanding is that there's ubifs for unmanaged flash and higher level filesystems for others.
<mangix>
jffs2 is used because of a lot of uboot implementations only supporting that and squashfs
<neggles>
mangix: yes, exactly, hence why hopefully jffs2/squashfs will be dead by 2106 :P
<neggles>
even if you want 50 years of devices to still be working without workarounds, which is probably a reasonable upper bound, that still give us 30 years to get to "everything new is booting off eMMC-type self-managed storage"
<neggles>
considering how far we've come since 1992, that seems reasonable
<neggles>
of course there's going to be That One Guy who's still using a TL-WR841N, but that's his problem
<Grommish>
neggles: You've got experience with rust projects.. Any idea where in there it would outline the linker it's trying to use?
<Grommish>
neggles: Ironically, the issue I'm having is with Suricata, which was the whole point of this adventure
<Grommish>
neggles: Although I'm suspecting it an issue with them rather than the rust install
<Grommish>
neggles: "/usr/bin/ld: /home/grommish/openwrt/build_dir/target-mips64_octeonplus_64_musl/suricata-6.0.4/rust/target/mips64-openwrt-linux-musl/release/deps/suricata.suricata.0708e34d-cgu.0.rcgu.o: Relocations in generic ELF (EM: 8)" There is no way it should be trying to use /usr/bin/ld :D, but I can't find where it might be hiding and grep'ong for "ld" isn't helpful
<neggles>
Grommish: given that rustc uses llvm on the backend and you're passing `--set=target.$(RUSTC_TARGET_ARCH).linker=$(TARGET_CC_NOCACHE)`
<Grommish>
neggles: On the toolchain, yes, but I'm talking on the suricata packaging
<neggles>
run with `V=sc` and CONFIG_BUILD_LOG=y then check logs/package/path/to/suricata
<Grommish>
neggles: I use make -j1 V=sc package/feeds/packages/suricata6/{clean,compile} 2>@1 | tee suri-build.log - is it different/better?
<neggles>
yes
<Grommish>
ok
<neggles>
CONFIG_BUILD_LOG=y splits out every target log into its own file
<neggles>
it's nice and clean
<neggles>
Grommish: suricata is using automake so it's probably looking for an LD env var
<neggles>
yep
<Grommish>
But, that should be in CONFIGURE_VARS
<neggles>
you're using a dist tarball right? not a github tarball?
<Grommish>
neggles: Yes, or, you can just add them to CONFIGURE_VARS += and CONFIGURE_ARGS +=
<Grommish>
Yes, autotools typically fals
<Grommish>
as part of PKG_FIXUP := autoreconf
<neggles>
okay...
<neggles>
also line 129, configure: WARNING: using cross tools not prefixed with host triplet
<Grommish>
Keep going and you'll see it finds all the goodies, include the ld.gold I use :/
<Grommish>
Yes, that's an AC_FILE_CHECK they had to bypass I believe
<Grommish>
because during a cross it can't validate files
<Grommish>
I bug repoted it back on Suricata5, but I'd have to dig out the exact code for it
<Grommish>
neggles: and the HOST would be x86_64-unknown-linux-gnu with target being the mips-musl
<Grommish>
neggles: checking if the linker (mips64-openwrt-linux-musl-ld.gold) is GNU ld... yes
<neggles>
um, shouldn't it be build=x86_64-unknown-linux-gnu and host/target=mips64-openwrt-linux-musl
<Grommish>
See, it finds it :D I just fails to use it later on and tries to use the host LD it looks like
<neggles>
it's trying to link thru `cc` rather than `gcc`
<Grommish>
neggles: No, Host is the Destination Arch
<Grommish>
neggles: Along with Target and Build is the system it's being crossed on, but, I'm still setting HOST to the GNU and Target to mips
<Grommish>
neggles: I did have to set 2 targets on the toolchain because I'm no longer building the full toolset
<Grommish>
so it would actually build std-lib for x86_64 as well
rua has quit [Ping timeout: 480 seconds]
<neggles>
is... is this not building for mips64-openwrt-linux-musl? i have never been able to wrap my head around what the build/host/target combo is actually meant to mean
<neggles>
but, 955, error: linking with `cc` failed: exit status: 1 - i imagine that should be reading `linking with mips64-openwrt-linux-musl-gcc failed`
rua has joined #openwrt-devel
<neggles>
from what i can gather from the gcc docs, when building the toolchain you want --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=mips64-openwrt-linux-musl, but for actual finished code/libraries you want --host == --build?
<Grommish>
--build should be x86_64, host should be x86_64, --target should be mips.. yes.. Only some projects recognize --build
<neggles>
not remotely sure about that, but one way or another `rustc` is calling `cc` rather than `<tuple>-$(CC)` for linking
<Grommish>
*nod* I'm testing a change and seeing it ifails
<neggles>
line 957 is the actual command it invoked
<neggles>
which started with "cc" "-Wl,--version-script=/home/grommish/openwrt/tmp/rustcWOo9sX/list"
<Grommish>
neggles: Topic jump because I just thought of it.. Any experience iwth PepWave devices?
<neggles>
specifically 'Configure the target linker and archiver only for this project.'
<neggles>
but since this is an isolated rust that will only build for openwrt, $CARGO_HOME/cargo/config ? (CARGO_HOME="/home/grommish/openwrt/staging_dir/host")
<neggles>
aaaand there already exists a suricata/rust/.cargo/config.in which is turned into config.toml
<Grommish>
Oh, i thought you were talking about the toolchian itself.. fml
<Grommish>
Yes
<neggles>
the toolchain itself may or may not be the problem
<Grommish>
There is an Makefile and a Config.toml template
<neggles>
but
<Grommish>
for Suricata
<neggles>
it appears you gotta set LD per project
<neggles>
that rust-lang/rust issue i linked has some more details
<neggles>
ahahaha
<neggles>
"Alternatively, you can also use export CARGO_TARGET_ARMV7_UNKNOWN_LINUX_GNUEABIHF_LINKER=/usr/bin/arm-linux-gnueabihf-gcc (for the arm-linux-gnueabihf target in this example)"
<neggles>
so that's an option...
<Grommish>
Ugh.. Ugly, but I will try that next
<Grommish>
I can always stick those in the environmentals
<neggles>
i would suggest putting it in $CARGO_HOME/config.toml
<neggles>
shouldn't CARGO_HOME be staging_dir/host/cargo
<Grommish>
neggles: Only if you want to keep it separate. But, since no one could tell me how to add the path to the build system, I just left it there it is
<Grommish>
neggles: it just utilizes ./bin, ./lib, etc
<neggles>
i would expect you'd have to add some lines to your host/install that add symlinks from cargo/bin/ to bin/
<neggles>
if CARGO_HOME is set correctly it shouldn't matter if it's on path as long as everything in cargo/bin is symlinked afaik
<neggles>
on the peplink thing, do you have a firmware image for it / can you get a root shell on it?
kenny has quit []
<neggles>
oh i found the firmware
<Grommish>
neggles: I've not looked at it.. It's installed in a vehicle I"m outfitting along with some roof-top mounts, but aside from verifying it works, it isn't in use.. I just was asking because you've got all the knowledge in the Cellular space
<neggles>
Grommish: well the firmware update is an ext2 filesystem image but it contains what looks like a ramboot linux install with a set of encrypted fw images
<neggles>
it's mips32 and based on the specs it's almost certainly an mt7621
<neggles>
or some ath79 chip
<Grommish>
It's certainly older.. Only a Cat4 LTE device
danitool has joined #openwrt-devel
<neggles>
Grommish: that doesn't make it old, just industrial :P
<Grommish>
neggles: Well, that's what I need it for, so..
<neggles>
the mt7621 and friends are still very much alive and well in industrial
<Grommish>
neggles: I've got a decommissioned ambulance that I'm retrofitting as a mobile IT shop and needed something that I could have for wired/wireless/cellular in a small package
<neggles>
cause "industrial" usually just means "we built it with 105C rated parts, put it in an extruded aluminium enclosure, and are selling it for 4-10x the price"
<neggles>
Grommish: mikrotik wAP R + your choice of miniPCIe modem card :P
<Grommish>
neggles: Running on 12vDC? I'm not giving up a 120vAC outlet for it ;p
<neggles>
Grommish: yes, and it has a plug for + comes with a pigtail for ignition power sense so it can do soft-shutdown
<karlp>
neggles: plus (hopefully) an agreement to keep selling it for more than like one year :)
<Grommish>
neggles: Well, I've already got one, so I'm stuck with the Pepwave :D
<neggles>
karlp: true, but that's rarely a problem with mikrotik stuff... I like Teltonika's industrial LTE stuff as well
<neggles>
reasonably priced, no stupid licensing subscription garbage
<neggles>
Grommish: from the brief dig through this firmware i've just done, don't even try to openwrt it
<neggles>
they've got full secure boot to the point of having the firmware encrypted in the flash
<neggles>
decrypted by the bootloader
<neggles>
and it's storing the licensing/subscription info in there too
<neggles>
though it looks like it wouldn't be super hard to trick it into reprogramming those details via the `sethwinfo` script, if you can get root on it :P
<karlp>
I like how pep even advertises throughput of their "pepvpn" without encryption...
<jow>
I thought many people use vpn to circumvent geo blocking
<neggles>
isn't it just a proxy if it's not encrypted
<neggles>
taking the P out of VPN
<karlp>
I guess, but this is kinda marketted differently than that.
<karlp>
what's "band 71" ? why is that spoken aout separately?
<karlp>
oh, it' sonly 600Mhz stuff.
<karlp>
still bugs me how expensive lte modems are
<Habbie>
aparcar, i figured out why I never managed to build mvebu docker images locally - it's the same reason it's failing in the gitlab pipeline: there is nothing matching openwrt-*-rootfs.tar.gz for it on downloads.openwrt.org
<cbeznea>
ynezz: just wanted to specify that I built w/o db34b93331e9 ("toolchain: add a version that can be bumped to force toolchain/target rebuild") because it causes infinit loops in building some packages
<Habbie>
aparcar, hmm, that's only true for 19.07 - snapshots do have a mvebu/cortexa9 rootfs
<Habbie>
aparcar, ok, now i got it - you added targz feature flag on wednesday, now your pipeline just needs a rerun :)
goliath has quit [Quit: SIGSEGV]
<cbeznea>
ynezz: https://git.openwrt.org/23eb5dfb8b8 doesn't fix the infinite loop on my side. is it necessary to do a "make distclean" before trying it?
<ynezz>
what does it output then?
srslypascal has quit [Quit: Leaving]
<ynezz>
Toolchain build version changed (11.2.0-1 != ), running make targetclean
<ynezz>
that patch should be enough, if that .toolchain_build_ver file is empty/missing, then it shouldn't force rebuild
<cbeznea>
ok, I'll try make targetclean
<ynezz>
cbeznea: uh, no, it should work as it is
<ynezz>
if it doesn't work, then there should be that line visible in the build output "Toolchain build version changed (11.2.0-1 != ), running make targetclean"
<ynezz>
or it eventually does loop for another reason
Tapper has joined #openwrt-devel
<ynezz>
that rebuild is being forced in that script, so it's strange
<cbeznea>
ynezz: build worked with https://git.openwrt.org/23eb5dfb8b8 after make targetclean. I think previously I did something wrong on my side, I cannot say what at the moment.
<aparcar[m]>
mangix: please rebase your tools/* patches to use the added CI
Sagi has joined #openwrt-devel
<Sagi>
Hi! I'm trying to build debug builds of packages/net/mdnsresponder, following the developer documentation. I've selected debug builds and stripping method none in make menuconfig, but I somehow still end up with stripped binaries. I'm probably missing something obvious, but I'm not super at home with C compilers.
<Habbie>
Sagi, i haven't tried debug builds, but I did find that after building, several sizes of the same binary existed on my disk
<Habbie>
find . -name mdnsresponder
<Habbie>
might show some
<rsalvaterra>
aparcar[m]: Since I see you're in a toolchain mood, would you like to merge my binutils 2.38 support? :)
<Sagi>
Habbie: yeah, I did that (for the mdnsd binary, which is the one I'm interested in), but the two copies are both stripped.
<rsalvaterra>
(I've been using it for ath79/generic and ramips/mt7621 for about a week.)
<Sagi>
the build output shows STRIP=x86_64-openwrt-linux-musl-strip, which seems not to follow the 'none' I configured in make menuconfig.
<jow>
Sagi: that's just a variable, whether $STRIP is actually invoked matters
<jow>
Sagi: also you don't typically need to mess with the stri psettings as the artifacts in build_dir are unstripped
<jow>
OpenWrt only strips upon packing the .ipk
<jow>
and it doesn ot strip the orgiginals but the copies within staging_dir
<Sagi>
hmm
<Sagi>
thanks
<jow>
if the binaries in build_dir are stripped, then the upstream build system (mdnsd's makefile) is responsible
<jow>
furthermore it rarely makes sense to run unstripped executables directly on target
<jow>
usually it is enough to
<Sagi>
they appear to, at least if I am to believe the output of file and gdb on the resulting binaries.
<jow>
- make package/foo/{clean,compile} CONFIG_DEBUG=y
<Sagi>
yeah, that's what I'm doing. Let me pastebin some output
<jow>
yeah it's the upstream makefile doing the stripping
<Sagi>
oh, thanks
<jow>
Sagi: in the OpenWrt Makefile, ass MAKE_VARS += DEBUG=1
<jow>
*add
<jow>
that should prevent it
<Sagi>
hmm, not yet
<Sagi>
I'm not seeing .ipk files being built though, let me solve that first.
shibboleth has quit [Quit: shibboleth]
hauke has quit [Server closed connection]
hauke has joined #openwrt-devel
<Sagi>
hah, the DEBUG=1 changes the output path, now the installpart of the Makefile is failing. I should be able to fix that though.
<Sagi>
that's fixed now. Unfortunately the resulting binaries are still stripped. But now I know I should be looking more into the upstream Makefiles. Thanks jow
blocktrron has quit [Server closed connection]
blocktrron has joined #openwrt-devel
Gaspare has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]