**** BEGIN LOGGING AT Tue Aug 23 02:59:56 2011 **** BEGIN LOGGING AT Tue Aug 23 09:06:07 2011 Aug 23 12:10:51 anyone caring to discuss the finer points of arm-gcc and unresolved symbols in libgcc on 10.03? Aug 23 12:11:07 sorry unresolved symbols in zlib Aug 23 12:13:26 der_lunz: try 10.03.1 rc5 Aug 23 12:14:24 i checked out everything from svn yesterday, that should do it right? Aug 23 12:14:50 depends what you checked out. Aug 23 12:17:10 :-) right: base is at r27706, feeds are r27893. Since then i haven't seen any relevant changes on the mailing list, if this suffices. Aug 23 12:17:36 which tree? Aug 23 12:17:58 backfire Aug 23 12:20:14 yesterday i filed a bug of a related problem https://dev.openwrt.org/ticket/9988 . Today i digged deeper, and found problems related with my initial one Aug 23 12:21:46 does the same bug exist in trunk? Aug 23 12:23:42 back soon Aug 23 12:47:52 there are a couple related issues, leaving out those that where fixed by a complete recompile, there are only two I deem relevant: https://dev.openwrt.org/ticket/9303 may be the same issue, and https://dev.openwrt.org/ticket/5937 was fixed by modifying a LDFLAG, which I also tried. Aug 23 12:52:04 basically it boils down, to libz beeing compiled with the unresolved symbol __aeabi_uidivmod (that symbol is defined in libgcc). When trying to build a package which depends on zlib, as in my case libpng, the configure run fails with autotools failing to compile the testprogram for determining, if zlib is available. Aug 23 12:54:38 I came around this error, by supplying '-shared-libgcc' to libpng's configure flags. the libpng build went fine. But the next package libdirectfb still complained about unresolved symbols in libz.so. Another error, the same reason. Aug 23 12:57:11 currently i am trying to explicitely link zlib to libgcc.so , something that should not be necessary, but that is the only way i know how to get those symbols resolved Aug 23 13:01:45 can anybody point me out what's the right way to get libgcc linked (shared or statically, i don't care) with zlib? Aug 23 13:43:43 der_lunz: hm, can you try to append $(LIBGCC_S) to the affected packages TARGET_CFLAGS ? Aug 23 13:45:22 der_lunz: also iirc __aeabi_uidivmod is an optimization artefact Aug 23 13:47:44 not TARGET_CFLAGS, just LDFLAGS which would be the wrong variable, because it didn't show up in the console. I'll try your advice at once. Aug 23 13:49:39 oops Aug 23 13:49:47 I meant TARGET_LDFLAGS of course Aug 23 13:49:51 not CFLAGS Aug 23 13:51:45 speaking of makefiles, I've got something like TOOLS=$(KKSD)/toolchain-mips_gcc-*/usr/bin Aug 23 13:51:49 LD=$(TOOLS)/mips-openwrt-linux-uclibc-ld Aug 23 13:52:06 is it possible to have the * expanded? in the console log it works, but it shows the *, rather than what version and path that actually selected Aug 23 13:52:29 TOOLS=$(firstword $(wildcard $(KKSD)/toolchain-mips_gcc-*/usr/bin)) Aug 23 13:52:44 firstword because "wildcard" may match multiple locations Aug 23 13:53:13 though "lastword" is probably better, should select the latest version in most cases Aug 23 13:53:34 beauttttiful, that's exactly what I've been looking for :) Aug 23 13:54:51 jaow_laptop: nop. neither will work. both variables aren't set when I run compile. I've added the TARGET_LDFLAGS="$(LIBGCC_S) " \ in both line 31 and 43 of https://dev.openwrt.org/browser/branches/backfire/package/zlib/Makefile Aug 23 13:55:10 nothing was of them was shown. Aug 23 13:55:43 der_lunz: well in this particular case you should stuff it into line 30 (LDSHARED=...) Aug 23 13:56:06 der_lunz: and once again in line 42 Aug 23 13:56:22 der_lunz: but I think there's an even easier fix Aug 23 13:56:48 if you use gcc instead of ld for linking it should handle the correct libraries automatically Aug 23 13:57:18 is it ever likely to matter what order the -I and -L flags are for target-arch/usr/[inc|lib] or toolchain-arch? Aug 23 13:57:42 karlp: I tend to say that if it begins to matter we have a bug Aug 23 13:57:51 that was what I hoped :) Aug 23 13:58:14 was just hoping it wasn't something where an order was required, and I was expected to know it Aug 23 14:00:39 jow_laptop: arm-openwrt-linux-gnueabi-ld: cannot find libgcc.a Aug 23 14:01:03 interesting Aug 23 14:01:29 I think you should talk to nbd about this, he did some work on splitting out libgcc Aug 23 14:01:53 however before doing that, try using gcc instead of ld as linker Aug 23 14:01:54 specifying the path to libgcc.a did it! Aug 23 14:02:16 the LIBGCC_S variable is supposed to contain the correct -L as well Aug 23 14:02:22 see rules.mk in the buildroot topdir Aug 23 14:02:38 it does, I echoed it, but libgcc.a is in some other directory Aug 23 14:02:56 then it apparently misdetects the path Aug 23 14:03:19 the path to libgcc.so is correct, but libgcc.a is somewhere else Aug 23 14:03:30 ah Aug 23 14:06:49 yippie! it worked. I can also compile other packages depending on zlib, that wouldn't before. Aug 23 14:07:00 Thanks!! Aug 23 14:07:29 BTW. is there some cheatsheet of variables used in the Makefiles, and their exact meaning? Aug 23 14:08:00 hah! Aug 23 14:08:01 I wish Aug 23 14:08:13 it's spread out through reams of pages of man pages, manuals, and source code, Aug 23 14:09:09 ok. where should i start searching? i know a couple of them, but I fail to know what's the difference between say, CFLAGS and TARGET_CFLAGS. Aug 23 14:21:51 der_lunz: TARGET_CFLAGS is likely to be the CFLAGS passed to builds that are for the target system.. so used in the cross-compilation stage Aug 23 14:23:36 der_lunz: rules.mk and include/*.mk Aug 23 14:23:58 der_lunz: that implements most of the makefile rule infrastructure used by openwrt makefiles Aug 23 14:24:21 thanks, i've just stumbled over this treasure of documentation! Aug 23 14:34:52 This isn't really openwrt related, but I'm going to throw it out there. Aug 23 14:37:50 does anyone know why two of my "echo" lines in a makefile are causing "*** commands commence before first target." but not the other two? http://pastebin.com/1W4izNyY Aug 23 14:38:27 the other two, "building for OpenWRT" and "building for linux" both echo as expected, with "make PLATFORM=owrt" or just "make" Aug 23 14:40:33 karlp: I believe this is due to the OWRT_STAGING Aug 23 14:40:47 karlp: or your echo commands are not properly indented with a tab Aug 23 14:42:03 the echo's have a tab, if I use spaces, I get "missing separator. Stop" Aug 23 14:43:04 hi jow Aug 23 14:46:45 If I wanted to purchase a SoC to create my own board, would this be possible without ordering 10,000 of them? Aug 23 14:48:03 ok, fixed it: http://pastebin.com/diff.php?i=2aUjsCpy **** BEGIN LOGGING AT Tue Aug 23 16:51:08 2011 Aug 23 18:46:01 nbd: ping? Aug 23 21:27:10 anyone care to comment on the x509 patch I just submitted to openwrt-devel? Aug 23 22:48:30 fullstop: hmm yes but not so easy i think.. Aug 23 22:48:44 fullstop: if you look at the story behind bifferboard. started as a idea at home Aug 23 23:17:21 applejack: that x509 patch is quite big, can you explain a bit about its origins? Aug 23 23:22:00 fullstop: also farnell and digikey do sell mosth but not all SoC's but some packages are a bit imposible to solder by hand. Aug 24 00:39:49 jow_laptop: it's part of the gentoo patches **** ENDING LOGGING AT Wed Aug 24 02:59:57 2011