**** BEGIN LOGGING AT Fri Jun 17 02:59:56 2011 Jun 17 03:34:44 Hi! Jun 17 03:34:56 is there any procedure to load modules with parameters? Jun 17 09:57:56 xMff: ping Jun 17 10:31:56 mirko: pong Jun 17 10:35:23 jow * r27200 /packages/net/transocks/Makefile: [packages] transocks: fix unpack and build directory (#9571) Jun 17 10:36:00 weird, playing with rb493g, with both ar8316 switches apparently configured with all ports (0,1,2,3,4,5) in a single vlan, i can udhcpc -i eth1 and get a resolution. if i unplug cat5 from the poe port i get a eth0 link lost message, but i can still ping via the nearest 4 ports. the 4 further away ports seem dead, though i get a link light through them (can't ping though). Jun 17 10:36:39 trying to deduce what port is what Jun 17 10:38:26 jow_laptop: regarding the intrl/iconv stuff - libs like eglibc / glibc are providing their own functionality and libs - do you think there's still a need for the external ones? Jun 17 10:38:42 mirko: no, probably not Jun 17 10:38:57 I suppose you can just sprinkle mor conditional depends into nls.mk Jun 17 10:51:22 jow_laptop: okay, will do Jun 17 11:22:48 rwhitby * r27201 /trunk/package/kernel/modules/other.mk: package/kernel: Fixed missing CONFIG_HID_SUPPORT required for successful kmod-bluetooth compile. Jun 17 11:23:54 rwhitby * r27202 /trunk/target/linux/ixp4xx/generic/profiles/200-NSLU2.mk: ixp4xx: Removed kmod-madwifi from the NSLU2 profile, as the NSLU2 has not wifi capability out of the box. Jun 17 11:25:22 hi Jun 17 11:29:01 i have to write a c++ program and while i was testing it (it sends upd packets and receices them) it tried set sent some millions to my router - throughput was about 64mbit i got this this messages "Jun 17 06:48:02 server kern.info kernel: b44 ssb0:0: eth0: powering down PHY" about 30 times in dmesg and the systems reboots- i think the reboot is triggered by watchdog - why the packets arrive at the router its unresponsive all the time Jun 17 11:29:30 why/while Jun 17 11:30:02 is there a way to get rid of this message in dmesg and get the router up and running while things like this happen? Jun 17 11:30:28 the router is a wl500gp and is running 2.6.39.1 Jun 17 11:32:31 <^Willie^> hmm before i start reinventing a wheel.. is there already some kind of syslog filter in luci so that i can define personal settings for example sshd stuff in his own log file and seperate subtab in the menu ? Jun 17 11:48:23 ^Willie^ you have to look at the busybox site but i dont think its possible you would have to use syslog-ng for example to this ... Jun 17 11:54:35 <^Willie^> hmm i still need to change some stuff for examle /var can stay ondisk.. Jun 17 11:55:38 <^Willie^> tripolar: and thinking about adding a sub page to the syslog/dmesg page Jun 17 11:55:57 <^Willie^> cmatch checks for "\n" -> http://luci.subsignal.org/trac/changeset/3791/luci/trunk/modules/admin-full/luasrc/view/admin_status/syslog.htm Jun 17 11:56:53 <^Willie^> was thinking about filling dropbear there and lets have a look.. but my rdp connection to the vbox host crashed :( Jun 17 11:58:15 the cmatch is only for couting the lines in the buffer Jun 17 11:58:51 to make the textarea scale with the content Jun 17 11:59:41 jow_laptop: is this b44 ssb0:0: eth0: powering down PHY line a bug of the b44 driver? i found some discussion about it in the lkml - but they wrote it is somehow fixed Jun 17 12:00:16 tripolar: I don't know. If it happens in conjunction with high packet load then it sounds indeed like a bug Jun 17 12:01:35 jow_laptop: when i use the firewall to drop the packets everything is better but the router is still unresponsive - but when the eth goes down its no wonder i cant reach it - where should i file a bug about it? Jun 17 12:02:07 I don't know Jun 17 12:02:21 I would try upstream Jun 17 12:02:35 there was some activity on ssb lately Jun 17 12:03:02 jow_laptop: what is ssb? Jun 17 12:03:17 erm nvm Jun 17 12:03:31 I meant b44 Jun 17 12:03:35 anyway Jun 17 12:03:37 I don't know Jun 17 12:03:55 maybe i should ask nbd Jun 17 12:03:57 ping nbd Jun 17 12:45:57 <^Willie^> jow_laptop: hmm i do think diffrent about cmatch function cmatch(str, pat) Jun 17 12:46:42 ? Jun 17 12:46:46 <^Willie^> line 263 in http://luci.subsignal.org/trac/browser/luci/trunk/libs/core/luasrc/util.lua Jun 17 12:46:54 <^Willie^> @param pattern String containing pattern to find Jun 17 12:47:01 <^Willie^> looks like it can be used as filter to Jun 17 12:47:07 no Jun 17 12:47:16 <^Willie^> damn my bad Jun 17 12:47:21 "Count the occurences of given substring in given string." Jun 17 12:47:26 <^Willie^> indeed your right -> Count the occurences of given substring in given string. Jun 17 12:47:33 <^Willie^> just note it right now while typing :S Jun 17 12:47:37 of course I am, I wrote it ;) Jun 17 12:48:19 <^Willie^> jow_laptop: hmm guess i can better install syslog-ng and define my config like i used todo with syslog-ng setups right ? Jun 17 12:48:44 <^Willie^> and then start reading the luci/wrt example app Jun 17 12:50:45 oops Jun 17 12:50:49 yes Jun 17 12:52:13 <^Willie^> ok thanks Jun 17 15:01:15 * Chocky looks for the ramips maintainer Jun 17 15:01:26 * Chocky has patches and questions Jun 17 15:03:09 also looking for anyone who cares about glibc Jun 17 15:17:06 Chocky: juhosg usually isn't on irc Jun 17 15:19:17 hm, ok Jun 17 15:19:51 he does read the mailing list thoug Jun 17 15:27:56 I need help in how to resolve svn conflict during an svn commit. Anyone? Jun 17 15:28:13 update Jun 17 15:28:34 it should offer you various resolution strategies Jun 17 15:29:28 and most of the time a conflict during commit automatically gets resolved by the update without manual interaction Jun 17 15:29:36 unless the update touches the same lines Jun 17 15:30:11 jow_laptop: Looks like it is more complicated because an 'svn up' did not resolve the conflict. Jun 17 15:30:39 jow_laptop: perhaps, an SVN downgrade and then 'svn up' will do? Jun 17 15:31:03 mazilo: what is the actual problem= Jun 17 15:31:24 mazilo: you edit the file to match what you want then say svn resolve path/to/file Jun 17 15:31:37 and finally svn commit path/to/file Jun 17 15:32:06 jow_laptop: I did not use 'svn resolve' yet. Jun 17 15:32:40 sorry, svn resolved path/to/file Jun 17 15:32:54 well it just tells svn that there is no conflict anymore Jun 17 15:33:01 *but* edit and *check* it before Jun 17 15:33:13 make sure to remove any conflict markers Jun 17 15:33:46 jow_laptop: How to remove any conflict markers? Jun 17 15:34:28 with an editor? Jun 17 15:34:33 they look like Jun 17 15:34:38 <<< .r123 mine Jun 17 15:34:40 blah Jun 17 15:34:42 ==== Jun 17 15:34:44 foo Jun 17 15:34:51 >>> .r123 theirs Jun 17 15:34:54 or similar Jun 17 15:35:00 should be pretty obvious Jun 17 15:35:10 jow_laptop: OK. I will check that out. Thanks. Jun 17 15:35:28 in such a case you want to remove them and decide on either "blah" or "foo" Jun 17 15:35:57 if you're done and the file looks like you want do svn resolved on it, then commit Jun 17 15:42:05 Chocky: what's about glibc? Jun 17 15:43:12 just a sec Jun 17 15:44:36 mazilo * r27203 /packages/net/freeswitch/files/ (3 files in 2 dirs): fixed some mangling configuration files Jun 17 15:46:03 mazilo * r27204 /packages/net/freeswitch/files/etc.packages/tts_commandline/autoload_configs/ (. tts_commandline.conf.xml): additional configuration files Jun 17 15:46:24 mazilo: looks like you got it reolved Jun 17 15:46:29 https://dev.openwrt.org/ticket/9483 and also https://dev.openwrt.org/ticket/9201 Jun 17 15:47:50 jow_laptop: Yup. But, I did it in an awkward way. I renamed existing package (directory), retrieved the package, made the necessary changes, and did an svn commit. Jun 17 15:47:55 Chocky: did you try an older/newer version of binutils? Jun 17 15:48:34 for the latter? Not yet Jun 17 15:48:48 for the former, someone needs to apply the patches. please! Jun 17 15:49:53 Chocky: send me tested, well-formatted patches and i'll do so Jun 17 15:50:24 Chocky: or are you referring to https://dev.openwrt.org/ticket/7133 ? Jun 17 15:50:44 7133 is a start. Jun 17 15:51:18 For 8342, I'm not sure of the best patch. My setup is a hack. Jun 17 15:52:01 Chocky: yep :) Jun 17 15:52:27 well, let's address the issues one by one. Jun 17 15:52:43 Chocky: 8342: "This should be fixed in r26540. " Jun 17 15:52:57 I have a patch for the _start thing, and there's another patch for mysql Jun 17 15:53:00 should be, but it's not. Jun 17 15:53:18 Chocky: "Its works, thanks :). Jun 17 15:53:21 ;) Jun 17 15:53:29 -> last comment Jun 17 15:53:33 anyway Jun 17 15:53:50 indeed. but wrong, alas. At least for me. Jun 17 15:53:51 i'll look to the ones listed in 7133 Jun 17 15:57:09 I'm running glibc + trunk on sheevaplug, for reference Jun 17 15:57:25 mazilo * r27205 /packages/net/freeswitch/Makefile: additional patched files to support mod_mp4 (depends on libmp4v2 currently awaiting Travis to approve) Jun 17 15:58:50 mazilo * r27206 /packages/net/freeswitch/patches/ (2 files): Oops, here are the patched files Jun 17 16:02:52 jow_laptop: ping Jun 17 16:04:37 jow_laptop: I sent an email out a week or 2 ago suggesting a Wiki page about potential projects looking for collaboration... didn't hear anything back about that. Jun 17 16:04:48 Chocky: https://130.133.110.88/openwrt_glibc_binutils.patch - could you check and (N)ACK? Jun 17 16:05:01 ok, doing 6 things here, but will try ASAP Jun 17 16:05:07 the idea was that someone who's a good coder and someone who understands the service and its configuration issues could work together. Jun 17 16:05:38 the wiki page would be a way for them to find each other. how likely would it be to put up such a page? if it doesn't get used, we could tear it down, right? Jun 17 16:09:57 mirko: see also the patch I just added to the ticket Jun 17 16:33:48 mazilo: can you revert your PKG_REV change (again)? PKG_BUILD_DIR is redundant and already handled by include/package.mk too Jun 17 16:36:59 swalker: Already done that when Gerrit mentioned to me a few days ago. Thanks. Jun 17 16:38:09 swalker: He thought your update caused the weirdness on the FS package naming. Sorry about that. Jun 17 16:39:08 * swalker points to the changes r27205 actually made Jun 17 16:40:25 swalker: I am looking at my local OpenWRT Makefile for FS and it no longer contains PKG_REV entries. Jun 17 16:40:48 ... Jun 17 16:42:12 mirko: ack on those patches, I think. but now I have some new breakages. "I may be some time" Jun 17 16:44:58 swalker * r27207 /packages/net/freeswitch/Makefile: [packages] freeswitch: store the git hash in the PKG_REV variable Jun 17 16:45:33 mirko: regarding the asm constraints thing, older binutils versions don't help. What works, is using GCC 4.3.3. But I have relocation errors in the final filesystem. Jun 17 16:46:25 swalker: Now, I see your point. Jun 17 16:46:30 swalker: Thanks. Jun 17 16:49:30 looks like someone looked at one of nbd's packages that has said weirdness as well as an example Jun 17 17:15:34 moo Jun 17 17:47:20 mirko: really ack. Other issues seem to be transient build issues. Jun 17 18:29:55 hi Jun 17 18:29:57 ping nbd Jun 17 18:53:33 thepeople1: ping Jun 17 19:21:16 can I remove the crda from wireless? Jun 17 19:22:05 it's useless and it wastes time for boot.. Jun 17 19:55:50 yes you can Jun 17 19:57:52 do i need to pass an option while loading cfg80211? Jun 17 20:01:28 or, are there some config to delete it before compiling? Jun 17 20:02:02 moo Jun 17 20:02:31 jow * r27208 /packages/net/sshfs/Makefile: [packages] sshfs: link libintl if CONFIG_BUILD_NLS is active Jun 17 20:03:18 danitool: edit the source. I've beat the ath9k on my laptop into shape so that it does not any regulatory stuff at all :) Jun 17 20:04:10 ok, I'll do it Jun 17 20:06:05 * xMff thinks even digital rights management works better and has lower false positives than crda and its friends Jun 17 20:22:47 tripolar: pong Jun 17 20:38:06 xMff: crda isn't the problem Jun 17 20:38:14 crda is fairly simple and unproblematic Jun 17 20:38:22 it's the cfg80211 regulatory code that's crap Jun 17 20:38:32 yes ok Jun 17 20:38:32 but i've successfully convinced luis that it needs a rewrite Jun 17 20:38:36 and we'll work on that soon Jun 17 20:39:03 unfortunately that won't change the situation regarding the stupid atheros restrictions due to bogus regdomain codes Jun 17 20:39:39 but at least it'll hopefully get rid of spurious regdomain changes and rule intersections Jun 17 20:41:41 yet I wonder why we can't just encode the region into the image, like the oem does Jun 17 20:42:48 unfortunately that's not really in line with the FCC rules Jun 17 20:43:26 OpenWRT is FCC's bitch Jun 17 20:43:29 no Jun 17 20:43:50 but we're working together with qualcomm/atheros Jun 17 20:43:55 sure Jun 17 20:44:08 and we have agreed to not do stuff that might harm their position wrt. open source Jun 17 20:45:22 no doubt this is a can of worms question which has already long since been debated, but isn't that contrary to the spirit of OSS? I appreciate that practical matters always intrude Jun 17 20:45:24 we could just ignore the FCC crap and do our thing, but it wouldn't be good for long term cooperation with them and other chip manufacturers Jun 17 20:45:46 it's not against the spirit of OSS, because users can just bypass that crap if it's in the way Jun 17 20:45:52 the source code is fully open Jun 17 20:46:03 but we won't ship binaries that do this by default Jun 17 20:47:07 it's not like there's any obfuscation, drm, binary-only stuff or anything else in the way Jun 17 20:47:16 just asking :o Jun 17 20:47:39 <_trine> can we limit Greece to 1mW Jun 17 20:48:37 but i make my own binary, i only need the option to bypass it in the menus :P Jun 17 20:49:22 _trine: why? Jun 17 20:49:49 then they'd get mad and do stuff like this: http://wurstball.de/static/ircview/pictures/76489ce9ce5dd8728161160cf4c6e2d9.jpg Jun 17 20:49:52 ;) Jun 17 20:50:22 <_trine> heh Jun 17 20:51:45 <_trine> I've had a good day today,, for an anarchist that is Jun 17 20:52:10 * Chocky blames the Candians Jun 17 20:52:13 +a Jun 17 21:14:41 xMff: you should put a patch up somewhere Jun 17 22:21:02 la la la Jun 17 22:21:14 * Chocky compiles openwrt against glibc 2.13 Jun 17 22:25:48 Chocky: excellent! sizewise how is everything? Jun 17 22:26:36 it's still building. I don't even know if it'll work yet Jun 17 22:26:42 2.7 has issues under mips Jun 17 22:27:09 I think the gcc is perhaps too new or something. Jun 17 22:27:25 oh I understand you have it compiled... Jun 17 22:27:33 you mean glibc or eglibc? Jun 17 22:27:35 ... Jun 17 22:27:53 I mean glibc. Some older versions didn't get very far in compilation Jun 17 22:28:03 e.g. https://dev.openwrt.org/ticket/9201 Jun 17 22:28:26 cool! will watch your progress Jun 17 22:28:27 then I still need to wait for rest of openwrt against it, so it'll be a while Jun 17 22:28:55 I know that eglibc doesn't even build right now Jun 17 22:52:36 Chocky: i'm using eglibc in a production environment - why it isn't building for you? Jun 17 22:52:56 mirko * r27209 /trunk/package/hotplug2/Makefile: [package/hotplug2] link against 'libbsd' when using glibc Jun 17 22:52:59 mirko * r27210 /trunk/toolchain/glibc/patches/2.7/ (103-binutils_2_20.patch 104-binutils_2_20.patch): [toolchain/glibc] fix glibc to work with all versions of binutils, fixes #7133 - thanks to marek siller Jun 17 22:53:02 i think we should simply get rid of old eglibc versions Jun 17 22:53:32 I tried to build it for sheevaplug from trunk a few weeks ago. Sorry, I don't recall the precise issues, and yet it might well be fixed now. Jun 17 22:53:46 I would try again if I could justify the time. Jun 17 22:54:41 which may yet happen if this glibc thing doesn't work Jun 17 23:00:15 * Chocky talks to juhosg Jun 17 23:22:55 nbd: that should be done anyway Jun 17 23:24:07 hm, it'd be nice if uClibc++ didn't build when I'm building against glibc Jun 17 23:24:12 how can I turn that off? Jun 17 23:27:06 Chocky: that's tricky Jun 17 23:27:12 hm. Jun 17 23:27:24 Chocky: you can add "@!USE_UCLIBC" to DEPENDS Jun 17 23:27:25 cos it doesn't build; there's const char * errors from gcc Jun 17 23:27:32 however that would mysql not build either Jun 17 23:27:43 *wouldn't make Jun 17 23:27:58 but that builds - at least in my hack - against libstdc++ Jun 17 23:28:07 perhaps I can patch it. Jun 17 23:28:34 we need to write a uclibcxx.mk that takes care of the abstraction between libstdc++ and uclibc++ based on a feature flag Jun 17 23:28:41 please Jun 17 23:28:47 nbd: Chocky: i've started such a solution Jun 17 23:28:55 ah, good Jun 17 23:28:55 woo. Jun 17 23:29:19 where a package defines 'UCLIBCXX_CAPABLE' Jun 17 23:29:29 ? Jun 17 23:29:54 the package should just include uclibcxx.mk Jun 17 23:30:04 and have that file take care of it Jun 17 23:30:12 nah Jun 17 23:30:15 nah? Jun 17 23:30:24 there's the situation where a package can be built against libstdc++ and uclibc++ Jun 17 23:30:34 usually uclibc++ is a good choice Jun 17 23:30:35 that's exactly what i'm talking about Jun 17 23:30:49 however if you have at least one package which needs libstdc++ Jun 17 23:30:55 you have both libraries on your system Jun 17 23:31:07 packages that need libstdc++ use it without including uclibcxx.mk Jun 17 23:31:18 i was thinking about a setting like: 'use always stdc++' vs. 'use uclibc++ when possible' Jun 17 23:31:19 packages that can use uclibc++ will include that makefile Jun 17 23:31:28 and the feature flag decides whether to use uclibc++ or libstdc++ Jun 17 23:31:29 so a package needs to expose it's capability of working with uclibc++ Jun 17 23:31:50 its! Jun 17 23:31:52 imho the package does not need to expose the capability Jun 17 23:31:54 hm Jun 17 23:32:01 nbd: i guess you're right :) Jun 17 23:32:04 the system shouldn't just magically disable uclibc++ because there's a package that needs libstdc++ Jun 17 23:32:09 maybe that package can link statically Jun 17 23:32:13 and then uclibc++ still makes sense Jun 17 23:32:15 nbd: that wasn't my intention Jun 17 23:32:18 it should be up to the user to make that choice Jun 17 23:32:21 globally Jun 17 23:32:28 in the unusual case where a package doesn't work with one of them, put special rules in makefile, etc Jun 17 23:32:36 and then packages that support either of the two will make the choice based on the feature flag Jun 17 23:33:13 nbd: we're d'accord - despite i was thinking there's a need of exposing uclibc++-capabilities.. Jun 17 23:33:41 ok Jun 17 23:34:23 issue is packages which got patched to use uclibc++ instead of stdc++ are quite hackish.. Jun 17 23:34:39 I put a patch in for glibc for now. There's conflicts in the str* definitions Jun 17 23:34:44 anyway, will take a look into it tomorrow.. Jun 17 23:35:18 TBH, I'm not even certain *why* mysql gets compiled. I'm using sqlite lite for my php stuff. Jun 17 23:35:30 something must pull its lib in Jun 17 23:35:33 Chocky: hidden dependency Jun 17 23:35:41 how can I track it down? Jun 17 23:35:46 Chocky: was looking for it a while and didn't find it ;) Jun 17 23:35:51 aw. Jun 17 23:36:49 mirko: seems those 103-105 patches aren't even needed for latest glibc. oh well. Jun 17 23:37:45 Chocky: i'd suggest using eglibc if you can Jun 17 23:38:29 any reason other than that it works for you? Jun 17 23:39:42 nbd Hi. We had some weeks ago chat about my boot problems with eglibc and glibc based images with wzr-hp-g300nh. I was unable to get the network connection to boxes until I soldered the serial port and found out that apps could not find libraries until I created /etc/ldconfig.so.cache stuff for glibc/eglibc builds. You suggested that it should be done in a way that cache points to /tmp folder. Jun 17 23:39:52 Chocky: glibc is not meant for embedded devices Jun 17 23:40:06 blah, blah ;-) Jun 17 23:40:14 Chocky: eglibc is far more stripped down and contains lot's of patches regarding architectures other than x86 Jun 17 23:40:24 that's a better reason Jun 17 23:40:26 the glibc maintainer(s) did only care about x86 Jun 17 23:41:18 Chocky: you should let me finish speaking ;) Jun 17 23:41:27 well, I need this working like it did on sheevaplug under glibc, which was "good enough" for right now. that was glibc; I can change next week. Jun 17 23:41:30 Hi mirko and Chocky just realized that you also chatted about glibc/eglibc :-) Jun 17 23:41:59 huge amount of my time is consumed with various toolchain compinations Jun 17 23:42:07 er, compilations/combinations Jun 17 23:42:39 Chocky: i don't wanna 'convert' you :) - it's just i'll take care about eglibc now for a bit in openwrt Jun 17 23:42:47 good Jun 17 23:42:50 and i don't know much people using / caring about glibc Jun 17 23:43:58 well, I've seen enough bug reports in openwrt to see that some people care. Maybe, and perhaps justifiably, most of the maintainers don't. but it seems like the issues are easy to fix. Jun 17 23:44:03 lamikr: /usr/lib is not part of LD_LIBRARY_PATH by default in glibc/eglibc Jun 17 23:44:25 mirko: do you know why? I had that issue too, if you remember Jun 17 23:44:38 nbd or mirko any changes to get patches from "glibc and eglibc build and usage fixes" title send 2 weeks ago to trunk? For me they solved the problem and I did the patches in a way that it will not touch for uclibc builds. Jun 17 23:44:50 and adding to LD_LIBRARY_PATH in /etc/profile doesn't fix the matter entirely Jun 17 23:45:14 Chocky: well, if people tell me patches work and i can follow them i'm willing to commit these - however i'm not gonna setup a glibc toolchain soon.. Jun 17 23:45:25 Chocky: no, you have to add it to /etc/rc.common as well Jun 17 23:45:30 Chocky: however this is a hack anyway Jun 17 23:45:39 that's fine, just address the issues you already said you would for that bug report ;-) Jun 17 23:46:16 mysql and that _start thing, most obviously. I might have something for glibc 2.13 Jun 17 23:46:29 i scrolled through the eglibc code but wasn't able to find a nice place to add /usr/lib straightaway Jun 17 23:47:20 Chocky: the hidden dependency needs to get figured out - affects eglibs as well.. Jun 17 23:47:23 hm, but it's like that on desktop systems. why is it different on openwrt Jun 17 23:47:32 mirko: certainly. Jun 17 23:47:37 Chocky: missing ldconfig / ld.conf.so Jun 17 23:48:24 so I can safely assume most everything you do for eglibc will be glibc relevant too. If you could keep that bug report updated, I'd appreciate it Jun 17 23:48:29 mirko Yes, my patches would add the ldconfig ld.conf.so Jun 17 23:48:36 and obviously /etc/ld.so.cache Jun 17 23:50:08 In the patch I created dynamic way for apps installed to add also some other dirs than /usr/lib to ld.so.cache Jun 17 23:50:51 ld.so.conf has only a line: include /etc/ld.so.conf.d/*.conf Jun 17 23:52:12 since openwrt works well without any other references than /lib /usr/lib i'd like to see /usr/lib hardcoded into eglibc Jun 17 23:52:35 no need of ldconfig / ld.so.conf / ld.so.conf.d/ ld.so.cache Jun 17 23:52:57 and then there is in /etc/ld.so.conf.d directory a base_library_path.conf file which contains /usr/lib line... But if some other app would want to have it's own lib added from some other dir, it could just install own conf file to /etc/ld.so.conf.d dir Jun 17 23:53:19 lamikr: why's that needed? Jun 17 23:53:23 and on next time the ldconfig is run, then also that dir would be included Jun 17 23:53:32 and how would you do so when using uclibc? Jun 17 23:53:41 lamikr: there's no ldconfig by default Jun 17 23:56:59 I added that in my patch by copying it from the toolchain build. (if I remember correctly). Jun 17 23:57:13 * lamikr trying to find the patch for checking details Jun 17 23:58:40 mirko http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg09699.html Jun 18 00:00:01 It copies it in base-files/Makefile nbd suggested putting the fixes there. Jun 18 00:00:43 lamikr: i still don't get why we need all that ld* stuff when we can just hardcode /usr/lib Jun 18 00:02:21 Well, this solution came to my mind because I also did not like from the LD_LIBRARY_PATH thing. Jun 18 00:03:17 lamikr: but it differs from the uclibc solution, so packages need to care about conditionals Jun 18 00:03:28 which i'd like to avoid Jun 18 00:04:10 and I thought also that it would be good if there is possibility to add dynamically more paths in case that somebody want to put some libs for example to usb harddrive mounted somewhere under /opt/usr/lib for example Jun 18 00:05:09 as said - i don't see how it'll work in conjunction with uclibc Jun 18 00:05:24 mirko Do you know some 3rd way which does this both without LD_LIBRARY_PATH and ld.so.cache? Jun 18 00:06:05 lamikr: no, and i still don't see the issue with hardcoding the path into eglibc :) Jun 18 00:07:42 Chocky: please ping me regarding the other (e)glibc issues (i promised to address), if i don't get it done within the next few days.. Jun 18 00:08:28 mirko I did not know howto do this hardcoding, at the moment I am happy no matter which way it works. But of course I would like to see my way also in, as I though this extra install space support is also nice feature. (And I spend over one weekend for building and rebuilding in order to get this patch working nicely :.) Jun 18 00:09:55 I tested the patch both with the glibc and eglibc 2.1.2. Jun 18 00:11:30 mirko Do you know where will the library path hardcoding go in the eglibc? Jun 18 00:13:37 lamikr: 01:44 < mirko> i scrolled through the eglibc code but wasn't able to find a nice place to add /usr/lib straightaway Jun 18 00:16:20 I do not have any idea myself. I have build toolchains many time also from scratch without openwrt or oe, but for glibc/eglibc I have only done small build fixes and I don't really know well it's structure. Jun 18 00:19:20 mirko Another problem at least 2 weeks ago was the hotplug build, for that there patch adding functions that are not available in glibc/eglibc. https://dev.openwrt.org/ticket/9012 and also in my email: http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg09701.html Jun 18 00:19:40 lamikr: it's fixed now - take a look at the -dev ml Jun 18 00:21:21 mirko Ok, great. Found the thread. Jun 18 00:23:08 I need to get to sleep now, but please try to build one test image with the ldconfig patch. One advantage would be that it could work in a same way with many different glibc/eglibc versions. Jun 18 00:25:01 lamikr: still, it does not make any sense AFAIK for uclibc builds - which is the most common used libc-implementation in openwrt Jun 18 00:31:05 holy crap it works Jun 18 00:31:14 * Chocky has openwrt + glibc 2.13 Jun 18 00:31:23 :) Jun 18 00:31:39 Chocky: which architecture? Jun 18 00:31:43 you have no idea how much of a relief this is. I have a monday deadline Jun 18 00:32:39 well then :) Jun 18 00:33:13 Ralink RT3883 Jun 18 00:33:19 i.e, ramips Jun 18 00:33:38 ic Jun 18 00:35:03 Chocky: http://blog.aurel32.net/?p=47 Jun 18 00:35:26 old, old news Jun 18 00:35:28 ;-) Jun 18 00:35:59 Chocky: i send it to you because it summarizes the differences between glibc and eglibc Jun 18 00:36:05 ta. Jun 18 00:36:28 "(as opposed to this)." - these words are links to glibc bug reports - get popcorn and scroll through Jun 18 00:36:31 :) Jun 18 00:36:54 :o Jun 18 00:37:18 still, uclibc had a show stopping bug for me, which no one here really knew the answer to. Jun 18 00:37:29 and eglibc didn't build for me, so this is the path I'm on now. Jun 18 00:38:02 gotta try my actual code now, make sure it works. Jun 18 00:47:10 /* Fill in the information about the application's RPATH and the Jun 18 00:47:10 directories addressed by the LD_LIBRARY_PATH environment variable. */ Jun 18 00:47:13 *sigh* Jun 18 00:48:14 and i remember appending rpath-parameters to build flags by default does not work since the syntax of gcc and ld - when used for linking - is different Jun 18 00:58:59 mazilo * r27211 /packages/net/freeswitch/ (5 files in 4 dirs): Added support for mod_rtmp (Real Time Messaging Protocol) Jun 18 01:03:10 mazilo * r27212 /packages/net/freeswitch/ (5 files in 4 dirs): Fixed trac #9574 Jun 18 01:27:20 What sort of WAN-LAN throughput should I be seeing on WRT54G? Jun 18 01:28:07 Something is limiting speed to 1Mbps/128kbps. Trying to narrow it down. Jun 18 01:50:48 qos-scripts in the way? Jun 18 01:51:38 mooooooooooo Jun 18 02:04:35 nbd: thank you. Jun 18 02:05:08 Never thought of that, let alone knew it was enabled and limited to 1Mbps by default. Jun 18 02:28:20 Chocky: lamikr: just added /usr/lib to the default search path of ld Jun 18 02:29:46 \o/ Jun 18 02:30:31 was just about to write a hack to work around it. but I'll prolly still use it for the moment, I don't immediately want to rebuild the toolchain. **** ENDING LOGGING AT Sat Jun 18 02:59:56 2011