| 00:10.43 | *** join/#uclibc xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:10.39 | *** join/#uclibc wberrier (~wberrier@71-213-55-124.slkc.qwest.net) |
| 01:21.01 | *** join/#uclibc dileks (~dileks@p548B7833.dip.t-dialin.net) |
| 01:24.00 | *** join/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 01:34.13 | *** join/#uclibc wberrier (~wberrier@174-23-134-9.slkc.qwest.net) |
| 01:36.19 | *** join/#uclibc xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 02:25.30 | *** part/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 02:38.29 | *** join/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 03:18.36 | *** part/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 03:20.01 | *** join/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 03:41.40 | *** part/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 03:43.00 | *** join/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 04:09.33 | *** join/#uclibc xiangfu (~xiangfu@125.34.167.247) |
| 04:38.45 | *** join/#uclibc xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 04:47.01 | *** join/#uclibc risca (~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net) |
| 05:36.07 | *** join/#uclibc erwt (~erwt@122.170.104.85) |
| 05:51.52 | *** join/#uclibc Jorasse (~Jorasse@64-187.196-178.cust.bluewin.ch) |
| 06:05.54 | *** join/#uclibc porchao (~hato@eatkyo267188.adsl.ppp.infoweb.ne.jp) |
| 07:00.07 | *** join/#uclibc factor (~factor@r74-193-21-187.cnrocmta01.conrtx.tl.dh.suddenlink.net) |
| 07:06.54 | *** join/#uclibc Artemys (~quassel@stp25-2-82-234-232-91.fbx.proxad.net) |
| 07:34.41 | *** join/#uclibc smartin (52e7e007@gateway/web/freenode/ip.82.231.224.7) |
| 07:43.31 | *** join/#uclibc clio (~andrej@85.159.109.222) |
| 08:34.18 | *** join/#uclibc AnywhereIs (~edK@h62-133-168-70.static.bashtel.ru) |
| 08:39.43 | *** join/#uclibc AnywhereIs (~edK@h62-133-168-70.static.bashtel.ru) |
| 09:18.03 | *** join/#uclibc Jorasse (~Jorasse@bdi68-1-82-227-80-246.fbx.proxad.net) |
| 09:28.02 | *** join/#uclibc xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 09:33.15 | *** join/#uclibc clio (~andrej@85.159.109.222) |
| 10:09.22 | *** join/#uclibc ericbutters (~kuhne@business-213-023-195-122.static.arcor-ip.net) |
| 10:09.49 | ericbutters | hi :) puh.. anyone build firefox with buildroot sysroot? |
| 10:10.13 | ericbutters | or anyone cross-compiled firefox? |
| 10:10.40 | ericbutters | i know there is midori and that is cool... |
| 10:12.54 | ericbutters | my target is armv7 cortex-a8. maybe best way is by chroot.. but i need to go with qemu to do this? and firefox build is about 4GB so i need large disc space with qemu? |
| 10:14.36 | ericbutters | can not build on target itself because of the disc site |
| 10:14.43 | ericbutters | size not site ;) |
| 10:15.22 | dalias | haha |
| 10:15.34 | dalias | building firefox under qemu would take 10 years or something :) |
| 10:19.23 | ericbutters | :) ok |
| 10:19.29 | ericbutters | good point |
| 10:21.32 | ericbutters | dalias you can tell what best way to do this? |
| 10:24.56 | dalias | i have no idea if firefox even works on uclibc |
| 10:31.04 | ericbutters | i got external toolchain based on glibc |
| 10:46.03 | *** join/#uclibc luneff (~yury@85.26.184.182) |
| 10:59.49 | *** join/#uclibc ben1066 (~quassel@host109-152-46-144.range109-152.btcentralplus.com) |
| 11:27.55 | *** join/#uclibc mnt_real (~sinan@78.160.93.241) |
| 11:35.37 | *** join/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 11:39.45 | *** join/#uclibc antgreen (~user@bas3-toronto06-1177890229.dsl.bell.ca) |
| 12:36.15 | *** join/#uclibc smartin (52e7e007@gateway/web/freenode/ip.82.231.224.7) |
| 12:44.21 | *** join/#uclibc bkuhn (~bkuhn@fsf/director/conservancy.president.bkuhn) |
| 12:46.24 | *** join/#uclibc luneff (~yury@85.26.184.182) |
| 13:20.37 | *** join/#uclibc drwhom (~drwhom@hulk.soic.indiana.edu) |
| 13:39.14 | *** join/#uclibc luneff (~yury@85.26.184.182) |
| 13:54.25 | *** join/#uclibc x-fak (~WinGuru@ANancy-554-1-121-200.w109-217.abo.wanadoo.fr) |
| 13:54.25 | *** join/#uclibc x-fak (~WinGuru@reactos/tester/x-fak) |
| 14:23.44 | *** join/#uclibc wberrier (~wberrier@71-213-54-200.slkc.qwest.net) |
| 14:53.30 | *** join/#uclibc ben1066 (~quassel@host109-152-63-140.range109-152.btcentralplus.com) |
| 15:00.37 | *** join/#uclibc ibot (~ibot@rikers.org) |
| 15:00.37 | *** topic/#uclibc is discussion of uClibc, Busybox and Buildroot | uClibc 0.9.33.1 was released 11 Apr 2012 | uClibc++ 0.2.3 was released 11 Apr 2012 | busybox 1.19.4 was released 4 February 2012 | Buildroot 2012.02 was released 29 Feb 2012 | For general setup issues try #oe, #elinux or #edev |
| 15:06.37 | *** join/#uclibc ben1066_ (~quassel@host31-53-199-120.range31-53.btcentralplus.com) |
| 15:12.51 | *** join/#uclibc ben1066 (~quassel@host86-151-191-2.range86-151.btcentralplus.com) |
| 15:15.53 | *** join/#uclibc landley (~landley@140.242.26.2) |
| 15:44.42 | dalias | hi landley |
| 15:44.44 | dalias | seen this? |
| 15:44.45 | dalias | http://gcc.gnu.org/ml/gcc/2012-04/msg00054.html |
| 15:45.04 | dalias | i think it will be of interest to most of #uclibc actually |
| 15:45.19 | dalias | altho you probably don't care since gcc4 is gpl3 anyway |
| 15:45.52 | *** part/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 15:49.37 | *** join/#uclibc Buglouse (~Buglouse@176.31.24.226) |
| 16:03.20 | *** join/#uclibc NIN101 (~NIN@206.253.166.69) |
| 16:10.13 | *** join/#uclibc y_morin (~ymorin@ARennes-256-1-46-252.w90-32.abo.wanadoo.fr) |
| 16:15.15 | landley | dalias: sigh. |
| 16:15.26 | landley | Well, that means gcc 4.8 won't build toybox. |
| 16:15.33 | dalias | ? |
| 16:15.40 | landley | I've made a policy of using things like "this" and "new" as variable names since day 1. :) |
| 16:15.56 | landley | If you try to build it as c++, it won't. |
| 16:15.57 | dalias | landley, the message is very confusing. they're talking about gcc |
| 16:16.19 | dalias | yes it sounds like they want to compile every C program as if it were c++ |
| 16:16.26 | dalias | which is a hideously misguided idea |
| 16:16.36 | dalias | but actually they just want to compile gcc as if it were c++ |
| 16:16.38 | landley | It would screw up kernel compiles too. |
| 16:16.40 | dalias | then start writing all the new code in c++ |
| 16:16.54 | landley | dalias: oh that. THey announced that a year ago, lwn.net covered it. |
| 16:17.15 | dalias | well they started the effort back then |
| 16:17.19 | landley | I need to dig up qcc. |
| 16:17.25 | dalias | qcc? |
| 16:17.26 | landley | And actually make that work. |
| 16:17.36 | dalias | we really need a new compiler |
| 16:17.41 | landley | Oh, taking the tinycc front end and gluing qemu's tcg code generator to the back end. |
| 16:17.55 | dalias | ah |
| 16:18.01 | landley | http://landley.net/code/tinycc/qcc/todo.txt |
| 16:18.07 | landley | And http://landley.net/code/tinycc/qcc/commands.txt |
| 16:18.21 | dalias | i'd really like to see a new compiler |
| 16:18.25 | landley | I need to busyboxify my old tinycc fork so it does the swiss-army-knife thing, callable as "ld" and "as" and "cpp" and so on. |
| 16:18.28 | dalias | designed with sanity as its first goal |
| 16:18.42 | landley | And then I need to break off the code generator part and make tcg work there. |
| 16:18.56 | landley | tinycc is already 95% of the way to c99 compliance (my fork was, anyway). |
| 16:19.13 | landley | And tcg is very well supported by the qemu guys, with support for buckets of different targets and regular updates. |
| 16:19.17 | landley | And it's bsd licensed even. |
| 16:19.24 | dalias | yeah but how is the quality of the generated code? |
| 16:19.32 | landley | fairly sad. |
| 16:19.41 | landley | It's about what you'd expect from tinycc or qemu. |
| 16:19.52 | dalias | my philosophy about optimizing compilers is that the reason you need them is not to make your code faster |
| 16:20.01 | landley | It's code generated on the fly with compilation speed and simplicity of implementation the primary goals. |
| 16:20.11 | dalias | the reason you need them is to keep idiots from writing "high level assembly" instead of C |
| 16:20.32 | dalias | (which is sometimes dome for the sake of performance, sometimes for size) |
| 16:20.39 | landley | It does basic constant propogation (the spec requires that), and I was working towards getting it to do dead code elimination. |
| 16:20.54 | dalias | one great example is bswap32 |
| 16:20.55 | landley | It drops out || 0 tests, and + 0, and * 1, and so on. |
| 16:21.12 | landley | But it doesn't rewrite the code into something more efficient. |
| 16:21.16 | dalias | gcc4 correctly optimizes it (to single opcode on cpus that have it) if you just write the clean, naive C to do it |
| 16:21.38 | *** join/#uclibc y_morin_ (~ymorin@ARennes-256-1-49-180.w90-32.abo.wanadoo.fr) |
| 16:21.44 | dalias | and to see why that's appealing |
| 16:21.54 | dalias | look at the monstrosity in the glibc headers to do it |
| 16:22.20 | dalias | they use __builtin_constant_p to check if the argument is constant, and if so, use C arithmetic expressions |
| 16:22.29 | dalias | and if not, they use inline asm |
| 16:22.59 | landley | The various swap macros are in libc. endian.h I believe. |
| 16:23.10 | dalias | yes that's what i mean |
| 16:23.32 | dalias | glibc implements it with that monstrosity to get around the fact that the compiler (at the time) did not optimize the simple clean C for it |
| 16:23.33 | landley | dalias: these days I'm focusing on the smart phone displacing the microcomputer. |
| 16:23.40 | landley | mainframe -> minicomputer -> microcomputer -> smartphone. |
| 16:23.57 | landley | I want to steer the new 4th gen stuff out of the proprietary ditch, and save us a decade of reverse engineering everything. |
| 16:23.57 | dalias | and that's what always happens when the compiler can't optimize |
| 16:24.04 | landley | That means getting android self-hosting. |
| 16:24.25 | dalias | people whine about how horrible the code the compiler generated is, and "i could write it better in asm!" or "i could write it better unrolling that loop by hand!" and then they do it... |
| 16:24.29 | dalias | and the result is shitty code |
| 16:24.42 | landley | If I had time to work on qcc, it could run natively on the phone just fine. |
| 16:24.46 | dalias | so i've come to the conclusion that a good optimizing compiler is needed |
| 16:24.55 | landley | And then you can compile a more optimized (much slower) pass later on. |
| 16:25.11 | landley | dalias: quite possibly. The sane implementation under development seems to be pcc. |
| 16:25.28 | landley | http://pcc.ludd.ltu.se/ |
| 16:26.00 | dalias | pcc is nice and simple |
| 16:26.07 | landley | I'd say llvm/clang but that's written in C++. |
| 16:26.13 | dalias | but it doesn't optimize very well yet |
| 16:26.18 | landley | pcc is the one open/net BSD are behind. |
| 16:26.23 | landley | llvm is the one Apple is funding. |
| 16:26.37 | dalias | llvm/clang is like a repeat of gcc... |
| 16:26.49 | landley | Yeah, but at least it's not GPLv3. |
| 16:26.49 | dalias | lots of bloated layers of abstraction |
| 16:27.31 | landley | That was the Bagehot Moment for Apple. |
| 16:28.36 | dalias | the idea that you need more abstraction layers is bogus and outdated |
| 16:28.42 | landley | Unfortunately, right now I've bitten off more than I can chew. |
| 16:28.45 | landley | I need to get toybox to 1.0. |
| 16:28.50 | dalias | yeah |
| 16:29.00 | landley | I need to catch up on aboriginal linux releases so it can continue to be a good test environment for toybox. |
| 16:29.10 | landley | _and_ so it can someday be bootstrapped into a self-hosting android builder or some such. |
| 16:29.18 | dalias | btw does toybox do (or intend to do) utf-8 support in utils that need it? |
| 16:29.29 | dalias | fold, wc, etc. come to mind |
| 16:29.30 | landley | And I accepted the maintainership of the kernel's Documentation directory and have done nothing with it since. (Ok, it's only a been a week, but still.) |
| 16:29.38 | landley | dalias: yup. |
| 16:29.41 | dalias | cool |
| 16:30.00 | dalias | back in 2007 i implemented my own version of several of them because busybox's was broken... |
| 16:30.11 | dalias | oh, what about the 'printf' command (shell command)? |
| 16:30.13 | landley | It'll probably be a config thing, though. (Able to switch it off.) |
| 16:30.18 | dalias | does it do utf-8 right? |
| 16:30.23 | landley | dalias: it's on the todo list? |
| 16:30.27 | landley | I have a roadmap, you know. |
| 16:30.30 | dalias | ok :) |
| 16:30.40 | landley | http://landley.net/toybox/roadmap.html |
| 16:30.47 | dalias | i'm looking forward to being able to use toybox instead of busybox |
| 16:30.47 | landley | dalias: it doesn't do utf-8 yet. |
| 16:30.58 | landley | It's on the todo list, but not a priority at the moment. |
| 16:31.15 | landley | An awful lot of utf-8 support comes from just being 8-bit clean. |
| 16:31.31 | dalias | yes, for most tools. i'm talking about the ones that need to consider it specially tho |
| 16:31.34 | landley | The explicit utf-8 stuff is mostly making sure you advance by the right amount when eating characters. |
| 16:32.10 | landley | If you have a list thereof, it would probably save me time. I haven't done a triage pass on that yet. |
| 16:32.11 | dalias | fold needs to see characters (not bytes) and use wcwidth() on them to do its line-wrapping correctly |
| 16:32.23 | dalias | wc -m counts (multibyte) characters |
| 16:32.30 | landley | I remember wc has two flags, although I don't think posix-2008 required it... |
| 16:32.34 | landley | Yeah, that. |
| 16:32.36 | dalias | tr needs to work with characters (not bytes) |
| 16:32.55 | dalias | same for sed (but the regex part is easy as long as your regex lib does it right) |
| 16:32.58 | landley | Ah, http://pubs.opengroup.org/onlinepubs/9699919799/utilities/wc.html does require it. |
| 16:33.00 | dalias | and likewise grep |
| 16:33.24 | landley | For sed and grep I"m taking a "libc's problem" view right now, and then I may go back and write a regex library later. |
| 16:33.41 | landley | is not in a position to take notes on this at present. |
| 16:33.50 | landley | Could you email me? (Or better yet, the list. :) |
| 16:33.59 | dalias | :) |
| 16:34.08 | dalias | well sed also has a tr-like command |
| 16:34.12 | dalias | (non-regex) |
| 16:34.15 | landley | fold, wc, sed/grep, tr. |
| 16:34.17 | dalias | that one you have to handle yourself |
| 16:34.24 | landley | dalias: y? |
| 16:34.27 | dalias | yes |
| 16:34.44 | *** join/#uclibc ben1066_ (~quassel@host109-152-61-173.range109-152.btcentralplus.com) |
| 16:34.56 | dalias | btw speaking of regex, i've been optimizing my fork of TRE |
| 16:35.02 | landley | rewrote busybox sed more or less completely in ~2004, but that was a while ago... |
| 16:35.15 | dalias | i eliminated the need to pre-convert the regex to a wchar_t string before parsing it |
| 16:35.23 | landley | I've had a "start over and write a new regex library for uCLibc" on my plate for years, but never got around to it. |
| 16:35.35 | landley | It's down with qcc and hello world linux kernels as "would be nice, but I have a life". |
| 16:35.46 | landley | Cool. |
| 16:35.47 | dalias | and i'm going to eliminate the need to call mbtowc() during regcomp |
| 16:36.00 | dalias | erm i meant regexec |
| 16:36.07 | landley | Did you ever work out what license musl was going to be under? |
| 16:37.04 | dalias | instead making regcomp generate a _byte_ based automaton from the utf-8 regex string, and only decode characters out of it when needing to use character-class assertions |
| 16:37.39 | dalias | not exactly, but it will be something non-gnu and probably simple bsd or mit |
| 16:37.54 | landley | Cool. |
| 16:38.21 | landley | utf-8 is kinda brilliant. Low ascii just works, high ascii doesn't interfere. |
| 16:38.39 | landley | You only need to care about anything with the high bit set when you're looking for it, otherwise it's just passed through... |
| 16:38.42 | dalias | i'm waiting a bit to handle the license change stuff tho just because we're working on code/testing issues at the moment and trying to get releases out |
| 16:39.08 | dalias | i just rewrote the floating point parsing/conversion code to be correct, and working on new scanf that uses it |
| 16:39.49 | dalias | before it was a really dumb mult-by-10-and-add loop that's horribly wrong for large- or small-magnitude numbers |
| 16:40.09 | dalias | license issue i hope to tackle somewhere around 0.9.0 |
| 16:42.00 | landley | dalias: how close is musl to being self-hosting? |
| 16:42.26 | landley | I.E. if I drop it into aboriginal and try to build something and then build lfs under that... how deep with the shrapnel embed in the bystanders? |
| 16:43.17 | dalias | some of the ppl in #musl have built nearly 200 packages on it including X |
| 16:43.27 | landley | Cool. |
| 16:43.28 | dalias | but some patching has been required; not sure how much |
| 16:43.38 | landley | Patching of the packages, or patching of musl? :) |
| 16:44.02 | dalias | both, but when it's musl i get the fixes committed quickly |
| 16:44.28 | landley | I've built LFS 6.8 I think under uClibc, and it's an automated regression test ala http://landley.net/hg/control-images/file/73b8cbdef3b5/images/lfs-bootstrap/mnt/build/ |
| 16:45.08 | landley | I've also built beyond linux from scratch by hand, up through getting x booting with I think fvwm and a simple term program with xchess and xeyes and such for a demo, back in 2010. |
| 16:45.09 | dalias | if something's needed that's ugly but part of the published "gnu/linux" api (e.g. glibc manual, lsb standard, etc.) i'm generally open to adding it if it makes it so more programs build without patching |
| 16:45.12 | landley | Keep meaning to automate that too... |
| 16:45.27 | dalias | but one thing i'm harsh on is programs using internal implementation-details of glibc's headers |
| 16:45.31 | landley | That's pretty much what I'm doing with toybox. |
| 16:45.37 | dalias | like using __uid_t instead of uid_t, for NO REASON |
| 16:45.44 | landley | susv4 doesn't mention the existence of "mount", "init", and a bunch of other necessary stuff. |
| 16:45.49 | landley | Let alone losetup and mke2fs... |
| 16:46.05 | landley | dalias: yeah, I can get behind that. :) |
| 16:46.09 | dalias | when that comes up, i say send a bug report/patch to the maintainer |
| 16:46.43 | dalias | or __BEGIN_DECLS because they're too lazy to write #ifdef __cplusplus extern "C" { |
| 16:46.48 | landley | Probably need to collect said patches together in one place, although "here there be dragons maintaining buildroot"... |
| 16:47.11 | landley | #ifdef __cplusplus |
| 16:47.14 | landley | #error no |
| 16:47.15 | landley | #endif |
| 16:47.17 | dalias | :) |
| 16:47.43 | dalias | yes, -D__BEGIN_DECLS= -D__END_DECLS= will solve it too |
| 16:48.12 | landley | I'll burn that bridge when I come to it. |
| 16:48.19 | dalias | (assuming there's actually no C++ code) |
| 16:48.31 | dalias | oh, we got c++ working a while back |
| 16:48.44 | landley | I just spent ~3 weeks rewriting my dirtree stuff so I didn't need various code using readdir() _and_ scandir() _and_ rts.h |
| 16:48.56 | dalias | :) |
| 16:49.14 | landley | And to test it, I tried to convert the contributed ls.c over to use it... and wound up rewriting it from scratch because what the spec requires out of ls is _subtle_. |
| 16:49.29 | landley | And fiddly and evil and annoying. |
| 16:49.55 | landley | But I got the pieces in place and checked in the basics saturday. Ok, "ls -lR ." shows "." but the _design_ is right now... |
| 16:50.46 | dalias | yes, spec for ls is very subtle |
| 16:50.47 | landley | Meanwhile, upgrading to the current uCLibc hit the fact that "tar --exclude -cf - *" dies in current busybox with "invalid option -". |
| 16:51.02 | landley | And it turns out the bug _isn't_ the crazy "-f -" bit (why the...?) |
| 16:51.31 | landley | It's that having options with a dash after a longopt in tar doesn't work, because it's trying to do the "tar xvjf" thing with no dash. |
| 16:51.41 | landley | So it thinks the dash is an option. SIGH. |
| 16:52.01 | landley | (I got this right in the toybox option parsing stuff _three_years_ ago. Come on guys...) |
| 16:52.10 | dalias | :) |
| 16:52.18 | landley | My interaction with the busybox list recently has been explaining to them why reverting things I did in 2006 was a bad idea. |
| 16:52.24 | landley | It's _frustrating_... |
| 16:53.23 | dalias | :) |
| 16:53.25 | dalias | i saw |
| 16:53.59 | dalias | i wish there were a way to reliably determine if the loop device was created by losetup vs mount, tho.. |
| 16:54.18 | dalias | because when it's manually created by losetup, it would be much nicer not to delete it by default |
| 16:54.43 | dalias | (see my post to the list with a nasty example of how this behavior could bite someone not expecting it) |
| 17:35.25 | *** join/#uclibc NIN101 (~NIN@206.253.166.69) |
| 17:53.42 | *** join/#uclibc ben1066 (~quassel@unaffiliated/ben1066) |
| 17:58.03 | *** join/#uclibc wberrier (~wberrier@71-213-54-200.slkc.qwest.net) |
| 18:07.43 | landley | dalias: the way util-linux mount does it is look for a "loop=" entry in mtab. Which doesn't work when /etc/mtab is /proc/mounts, which you _need_ to do to support shared subtrees and such. |
| 18:07.53 | dalias | *nod*.. |
| 18:07.57 | dalias | i don't see a good solution |
| 18:08.11 | dalias | the whole idea of having to make loop devices in userspace is just supid |
| 18:08.26 | dalias | the kernel should just do it all internally when you try to mount a normal file |
| 18:15.11 | *** join/#uclibc ben1066_ (~quassel@host86-164-176-0.range86-164.btcentralplus.com) |
| 18:17.21 | *** join/#uclibc ben1066 (~quassel@host86-164-176-0.range86-164.btcentralplus.com) |
| 18:21.55 | nenolod | dalias: fclose(stderr) without dup2 is safe on solaris and hp-ux |
| 18:21.56 | landley | dalias: that's what the busybox mount/umont commands I wrote essentially give you. |
| 18:22.22 | landley | They have since been broken. *shrug* |
| 18:22.28 | nenolod | dalias: in some apps like ircd, squeezing as many file descriptors as you can is important, as 3 fds == 3 more clients you can support |
| 18:23.27 | nenolod | which doesn't sound like a big deal, but if you have only say, 100 fds, it can be a pretty big deal |
| 18:24.08 | nenolod | basically anything else that would involve longpolling too |
| 18:25.53 | nenolod | i generally believe allowing daemons (which don't want stdio *anyway*) to repurpose those FDs is a good thing |
| 18:28.39 | landley | nenolod: I've seen close(0);close(1);close(2) as part of daemonizing. |
| 18:32.03 | dalias | from a security standpoint i think it's a very bad idea. you never know what random code might try to use the standard streams (especially stderr) unless you've taken care not to use any third-party libraries |
| 18:32.40 | dalias | repurposing 0/1 is actually rather safe/clean |
| 18:34.38 | nenolod | dalias: in glibc, if you fclose(stderr), then later fwrite() to it, it will just do nothing |
| 18:34.51 | nenolod | dalias: this is the same behaviour as in solaris, and even in uclibc :) |
| 18:35.17 | dalias | yes, but accessing any FILE after it's passed to fclose is explicitly UB, per C |
| 18:35.22 | nenolod | yes, it is. |
| 18:35.38 | nenolod | i am trying to get the austin group to clarify that using stderr from library is bad practice |
| 18:35.46 | dalias | :) |
| 18:35.53 | nenolod | they seem to agree |
| 18:36.46 | nenolod | i just used glibc as an example there, as they are the largest offender with __libc_message() |
| 18:38.19 | landley | dalias: I've also pondered using sparse as a front-end for qemu's tcg: http://lwn.net/Articles/456709/ |
| 18:38.20 | nenolod | landley: yes, that is an important detail too -- fclose() is not necessarily required to close() the underlying FD |
| 18:38.30 | landley | dalias: I've also pondered using sparse as a front-end for qemu's tcg: http://lwn.net/Articles/456709/ |
| 18:38.35 | landley | nenolod: if it doesn't, it'll leak. |
| 18:39.52 | dalias | nenolod, fclose is required to close the underlying fd |
| 18:40.34 | dalias | The fclose() function shall perform the equivalent of a close() on the file descriptor that is associated with the stream pointed to by stream. |
| 18:40.52 | *** join/#uclibc ben1066_ (~quassel@host109-154-133-179.range109-154.btcentralplus.com) |
| 18:43.55 | *** join/#uclibc ben1066 (~quassel@host109-154-133-179.range109-154.btcentralplus.com) |
| 18:50.37 | *** join/#uclibc ben1066_ (~quassel@host86-151-190-134.range86-151.btcentralplus.com) |
| 18:57.48 | *** join/#uclibc ben1066 (~quassel@host86-151-190-134.range86-151.btcentralplus.com) |
| 18:58.23 | nenolod | dalias: oh, hmm :) |
| 18:59.15 | dalias | :) |
| 19:05.02 | *** join/#uclibc ben1066 (~quassel@host109-152-55-48.range109-152.btcentralplus.com) |
| 19:11.07 | *** join/#uclibc ben1066_ (~quassel@host86-168-179-136.range86-168.btcentralplus.com) |
| 19:14.56 | *** join/#uclibc ben1066 (~quassel@host109-152-54-95.range109-152.btcentralplus.com) |
| 19:15.24 | *** join/#uclibc wberrier (~wberrier@71-213-54-222.slkc.qwest.net) |
| 19:21.30 | *** join/#uclibc ben1066_ (~quassel@host86-163-134-110.range86-163.btcentralplus.com) |
| 19:33.28 | *** join/#uclibc ben1066 (~quassel@host109-152-54-11.range109-152.btcentralplus.com) |
| 19:59.53 | *** join/#uclibc bkuhn (~bkuhn@fsf/director/conservancy.president.bkuhn) |
| 20:02.22 | CIA-146 | 03jacmet 07master * r581af082c517 10buildroot/package/boost/boost.mk: boost: cleanup |
| 20:02.25 | CIA-146 | 03jacmet 07master * r8b354dac5a41 10buildroot/package/boost/ (Config.in boost.mk): boost: fix build with uClibc, add locale/timer modules options |
| 20:09.13 | CIA-146 | 03gustavo 07master * rcf9e38ff8247 10buildroot/package/sshfs/sshfs.mk: sshfs: bump to version 2.4 |
| 20:09.13 | CIA-146 | 03gustavo 07master * r5fac9e034b41 10buildroot/package/unionfs/ (unionfs-make-mandir.patch unionfs.mk): unionfs: bump to version 0.25 |
| 20:09.13 | CIA-146 | 03gustavo 07master * r39c8e4d80cc3 10buildroot/package/multimedia/ffmpeg/ffmpeg.mk: ffmpeg: security bump to version 0.8.11 |
| 20:11.25 | *** join/#uclibc wberrier (~wberrier@71-213-54-235.slkc.qwest.net) |
| 20:34.37 | CIA-146 | 03yegorslists 07master * r5d8af3747afb 10buildroot/package/boost/boost.mk: boost: pass -dumpversion to user-config.jam |
| 20:36.05 | *** join/#uclibc risca (~risca@wi-secure-3075.cc.umanitoba.ca) |
| 21:13.04 | CIA-146 | 03jacmet 07master * re530970c28ac 10buildroot/package/libhid/libhid.mk: libhid: don't build with -Werror |
| 21:19.47 | CIA-146 | 03ludovic.desroches 07master * r7c717bbfffea 10buildroot/support/scripts/apply-patches.sh: apply-patches.sh: patch pattern was expanded prematurely |
| 21:22.00 | *** join/#uclibc shidum (~shidum@23.167.76.188.dynamic.jazztel.es) |
| 21:22.59 | *** part/#uclibc shidum (~shidum@23.167.76.188.dynamic.jazztel.es) |
| 21:45.46 | *** join/#uclibc risca_ (~risca@wi-secure-3075.cc.umanitoba.ca) |
| 21:55.52 | y_morin | khem: thank you for the pointer to the gcc-4.7 fix! :-) |
| 21:58.16 | khem | np |
| 21:58.36 | khem | I have been playing with 4.7 for few months now |
| 22:02.19 | dalias | you are brave :-p |
| 22:02.56 | *** join/#uclibc wberrier (~wberrier@174-23-145-46.slkc.qwest.net) |
| 22:04.44 | *** join/#uclibc sh4rm4 (~sh4rm@gateway/tor-sasl/sh4rm4) |
| 22:06.09 | khem | dalias: usually it needs some scapegoats like me before it makes into larger acceptence |
| 22:12.30 | dalias | well 4.7.0 should not be in acceptance; it generates bogus code |
| 22:12.44 | dalias | but apparently there's a fix now :) |
| 22:13.23 | khem | yes I see it that its branched out and then hardened over a period of time |
| 22:13.37 | khem | so 4.7.1 is better then 4.7.0 and so on |
| 22:14.14 | landley | How many prerequisite packages is gcc 4.7 up to? Have they hit double digits yet? |
| 22:14.36 | khem | heh infact libelf is no more needed |
| 22:14.37 | dalias | :) |
| 22:14.54 | dalias | really i blame llvm |
| 22:14.54 | khem | well that was the case with 4.6 as well so its even steven |
| 22:15.12 | dalias | it's competition with llvm that's driven gcc to become so crappy |
| 22:15.56 | khem | both have their own strengths I thinks one wont sweep another |
| 22:15.58 | dalias | and to want/need c++ |
| 22:16.18 | dalias | writing decent C code takes a lot more time |
| 22:16.27 | landley | dalias: no, they were pretty crappy before. |
| 22:16.27 | khem | c++ ainst that bad if one knows it |
| 22:16.31 | dalias | and when you're in a race with somebody else using c++... |
| 22:16.35 | dalias | c++ is that bad |
| 22:16.48 | landley | khem: c++ is worse |
| 22:17.13 | dalias | the vase majority of bloat comes from c++ and c++-like design written in c |
| 22:17.16 | dalias | vast* |
| 22:17.18 | khem | landley: I disagree but yes it was half step |
| 22:17.28 | khem | java was better |
| 22:17.31 | dalias | haha |
| 22:17.49 | landley | Back when I was on speaking terms with Eric Raymond we were working on a paper called "Why C++ is not my favorite language". |
| 22:17.55 | landley | It was very, very long. |
| 22:17.56 | khem | and now we have more frameworks like scala, ruby, etc. which has taken software design to another level |
| 22:18.19 | dalias | that's fine for "leaf" apps |
| 22:18.32 | dalias | but the trunk/roots of a system need to be written in c |
| 22:18.50 | landley | The thesis was that C is a portable assembly language, with very little abstraction between you and what the machine is doing. |
| 22:18.53 | khem | landley: problem is that an average person should be able to program a computer in modern world so called average programmer |
| 22:18.55 | dalias | of course part of the problem is that gcc seems themselves more as leaf than trunk/roots these days |
| 22:19.08 | khem | and you need good typesafe languages |
| 22:19.16 | dalias | landley, i disagree with that :) |
| 22:19.23 | landley | Scripting langauges like python have dynamic memory management, dynamic typing, resizeable containers (including dictionaries) as first class types. When they bother doing object orientation, their class instances are built on top of dictionaries. |
| 22:19.23 | dalias | C used poorly is high level assembly |
| 22:19.48 | landley | C++ is this horrible worst of both worlds thing that piles lots of abstractions on top of C and then never removes pointers, static typing, or static memory management. |
| 22:19.51 | dalias | C used well is a high-level language, but one that does not insulate you very much from the costs of what you're doing |
| 22:19.56 | landley | The result is abstractions that leak all over the place. |
| 22:20.00 | khem | I have seen better designed software in C++ than in C |
| 22:20.02 | dalias | i.e. in C++ you can write one line and have it compile to 20 megs due to templates :-p |
| 22:20.16 | dalias | in C, you have to *work* to make something big |
| 22:20.18 | landley | dalias: it's worse than that, templates are turing complete at compile time. |
| 22:20.36 | landley | There is no guarantee that a C++ program compilation using templates will EVER COMPLETE. It's got the halting problem. |
| 22:20.43 | dalias | :) |
| 22:20.50 | landley | No really, there's a paper on this... |
| 22:20.55 | dalias | i believe it |
| 22:21.18 | dalias | btw.. |
| 22:21.24 | landley | http://yosefk.com/c++fqa/ |
| 22:21.27 | dalias | i just read the other day in the mozilla coding guidelines |
| 22:21.34 | landley | (That's not the paper.) |
| 22:21.34 | dalias | they ban the use of exceptions for being non-portable |
| 22:21.53 | dalias | which means their policy is that mozilla products have to crash in resource exhaustion |
| 22:22.01 | khem | yes dont use multiple inheritence, rtti |
| 22:22.08 | dalias | in C++, as long as you use any non-trivial classes, the only way to handle resource exhaustion is exceptions |
| 22:22.13 | khem | reinterpret_cast |
| 22:22.18 | landley | khem: trying to pare C++ down to a "sane subset" is like trying to pare perl down to a sane subset. |
| 22:22.26 | landley | It means no 2 projects can share code. |
| 22:22.34 | khem | landley: thats why I said it was half measure |
| 22:22.54 | dalias | khem, i've seen a lot of bad C too, but it's very possible to write good C |
| 22:23.09 | khem | landley: I think modern languages have got it better |
| 22:23.10 | dalias | it's not possible to write good C++ unless you restrict yourself to the intersection of C++ with C |
| 22:23.13 | landley | No language has ever made it the least bit difficult to write bad code. |
| 22:23.15 | khem | languages like scala, go |
| 22:23.15 | dalias | and then you're just writing uglified C |
| 22:23.36 | landley | dalias: c99 sucked in the good bits. Single line comments and such. |
| 22:23.43 | dalias | landley, i beg to differ. bf made it difficult by making it difficult to write ANY code :-p |
| 22:24.01 | khem | since stupidity is infinite there is nothing to stop it :) so bad programs will exist in any language |
| 22:24.12 | landley | I remember Eric Raymond fanboying over precisely one open source code contribution he got. |
| 22:24.16 | landley | From Donald Knuth. |
| 22:24.21 | landley | It was a patch to intercal. |
| 22:25.47 | dalias | basically all the ideas in C++ are obsolete by the time they get deployed widely :-p |
| 22:26.19 | dalias | for example, classical OOP is obsolete for pathologically bad performance with multi-threading, among other reasons |
| 22:26.44 | dalias | massive inlining (templates) is obsolete since the instruction cache was invented... |
| 22:27.04 | dalias | etc |
| 22:27.30 | dalias | anyway i gotta go, bbl |
| 22:33.57 | CIA-146 | 03fhunleth 07master * r2f41adabc5a1 10buildroot/package/ (Config.in libdmtx/Config.in libdmtx/libdmtx.mk): New package: libdmtx |
| 23:13.12 | *** join/#uclibc Jacmet (~peko@stolen.plutonium.dk) |
| 23:32.58 | *** join/#uclibc factor (~factor@r74-193-21-187.cnrocmta01.conrtx.tl.dh.suddenlink.net) |