ibotlog2html for #crosstool-ng

<< Previous 2016-06-06 Next >>

# 00:00:01 ghostbsdun Looks like I'm developing something very similar to it
# 00:00:39 lundmar ghostbsdun: yup ;)
# 00:02:52 lundmar ghostbsdun: you can take a look at the buildfiles - they are _very_ straightforward, for example: https://github.com/mini-distribution/cross-core/blob/master/wget/Buildfile
# 00:03:55 lundmar quits : Quit: WeeChat 1.4
# 00:04:17 lundmar joins #crosstool-ng
# 00:04:56 lundmar it is non-nonsense meta data thanks to a sysrooted ct-ng which is the compiler backend :)
# 00:06:12 ghostbsdun sysrooted? Do you mean that tools are patched to modify file paths?
# 00:07:57 ghostbsdun Ohh, it's in Ruby too =)
# 00:09:02 lundmar ghostbsdun: no, the great thing about buildgear is that it uses the ct-ng toolchains sysroot as a staging area so that it does not need to use a lot of compile flags to specific where sysroot is when compiling components. its implicit.
# 00:09:17 lundmar ghostbsdun: what?? ruby, NO!
# 00:10:07 ghostbsdun Ohh, Buildfile is recognized by GitHub as Ruby source
# 00:11:02 lundmar pffft
# 00:13:49 lundmar ghostbsdun: anyway, I actually authored buildgear because I've found tools like OE, buildroot, etc. have too complex/noisy meta data which makes it troublesome. I wanted something simpler but still powerful.
# 00:16:12 lundmar ghostbsdun: I'm looking for contributors so maybe give it a try ;)
# 00:21:25 ghostbsdun lundmar, The idea of my tool is also simplicity and also Unix-way. However my main goal is building desktop operating systems. There is one problem with Linux - Red Hat and Lennart Poettering. I don't want to say that tools which they build (systemd, btrfs-based package distribution) are bad. However they are designed to solve Red Hat's problems and don't follow unix-way. The alternative should exist. So I want to build min
# 00:21:25 ghostbsdun imalistic are simple solution to remove dependency-hell. It will also support Btrfs volumes, but it will not depend on it. So I need tool to build basic Linux system with ease
# 00:22:48 ghostbsdun lundmar, I'm interested in your project, so maybe I can help. My email is ghostbsdun@yandex.ru, so you can contact me even if I'm not here.
# 00:23:59 lundmar ghostbsdun: well, I share you sentiment. systemd is not bad but it is turning in to a full fledged system layer which is problematic if it does not support your needs.
# 00:24:28 ghostbsdun Yes, that's what I think
# 00:25:16 JakeSays yeah i dont have a problem with doing things in a non-unix way if it is an improvement
# 00:25:28 lundmar one can also argue systemd is exactly what Linux needs to minimize fragmentation so its kind of a lesser evil situation.
# 00:26:08 JakeSays how does systemd minimize fragmentation?
# 00:28:37 lundmar JakeSays: it is likely that most distributions will adopt systemd eventually and in doing so it means that theu will use systemds solutions of eg. network manager, volume manager, standard init scripts etc..
# 00:28:50 ghostbsdun I'm a web developer. I use Docker in production, so I don't care about what init system is used in the system. However someone (why maybe develops complex daemons) can find that systemd helps in creating the product which will work in multiple different Linux distributions.
# 00:29:39 ghostbsdun *who maybe develops
# 00:30:28 JakeSays lundmar: thats not fragmentation - its just standardization
# 00:30:30 lundmar also, fact is that systemd brings alotta new features that most distros want, but unfortunately they have to take it all or nothing.
# 00:32:02 lundmar JakeSays: I mean fragmentation on a component level. If say distros stop using network-manger or connman, they will eventually die off and thus less fragmentation.
# 00:32:14 lundmar less choices for network managers.
# 00:32:30 JakeSays fewer choices is *definitely* not the linux way
# 00:33:32 lundmar true, but it is ironically also the biggest problem for the expansion of of GNU/Linux systems.
# 00:33:34 lundmar -of
# 00:34:14 ghostbsdun lundmar, you can look at my package format if you are interested https://github.com/lainix/linux-from-scratch.libertude/tree/master/tools/binutils-2.26-pass1
# 00:34:57 ghostbsdun I also want to target non-Linux kernels too. For example, my packages are built successfully in FreeBSD
# 00:38:23 lundmar ghostbsdun: regarding buildgear and building for desktop. While buildgear is designed as a crosstool build tool it can easily be used for non-cross. It would simply result in a colletion of "native" buildfiles.
# 00:39:21 lundmar ghostbsdun: I think it is problematic that your build actions are spread across so many files. It makes it difficult to get a quick overview of how things are built.
# 00:40:37 lundmar ghostbsdun: Also, I don't like json. One might think json is human readable but it really isn't that read friendly and it is even harder to create. Just my opinion.
# 00:41:03 ghostbsdun Yes, my package format is just prototype. I also have idea to make packages fully declarative
# 00:41:48 ghostbsdun I found that JSON is the most simple and fleible way to start
# 00:41:53 ghostbsdun *flexible
# 00:41:57 lundmar ghostbsdun: I fully understand hat you are trying. I've been there myself. After many iterations I came to the format of the buildfile. You can't make it simpler than that ;)
# 00:42:05 lundmar what*
# 00:43:12 lundmar also, all software that we build is focused around bash environments so it makes a lot of sense sticking to bash (buildfile is bash interpreted).
# 00:44:59 ghostbsdun It's not a problem to install bash on any system. However I don't need bash features so I use unix shell
# 00:46:25 lundmar ghostbsdun: ehh, what do you mean by unix shell? You mean the original Unix?
# 00:46:33 lundmar bash is a *nix shell if you like
# 00:46:50 lundmar used by 90% of all GNU/Linux systems
# 00:46:57 ghostbsdun dash, busybox's ash
# 00:47:05 ghostbsdun lundmar, also how does your tool support binary packages?
# 00:47:48 lundmar ghostbsdun: yes, it builds binary packages but they are mainly for temporary used during build of the fs.
# 00:48:25 lundmar ghostbsdun: in the buildfile, everything that is put in $PKG ends up in a package.
# 00:48:44 ghostbsdun I've strongly separated build and installation because users don't want to wait for compilation
# 00:49:18 lundmar ghostbsdun: you don't want to build using dash/ash etc.. A lot of software fails to build under those shells.
# 00:51:36 ghostbsdun My application runs my scripts in dash/ash, however make is running in subshell so it can use bash, as I understand
# 00:52:02 lundmar ghostbsdun: buildgear builds all components once and then they are cached so it does not rebuild anything unless required.
# 00:52:30 ghostbsdun I want to strongly determine build and runtime dependencies of every package with continuous building
# 00:52:45 ghostbsdun So if build requires bash, it will have bash as build dependency
# 00:53:25 lundmar sure, a build tool without dependency support is no good.
# 00:53:26 ghostbsdun If it doesn't, build will fail on base system during continuous building
# 00:53:42 ghostbsdun Yes, I don't support dependencies now =)
# 00:54:27 lundmar well - you better go study acyclic directed graphs then ha ha
# 00:54:40 ghostbsdun I have trouble with how to determine versions
# 00:55:00 ghostbsdun Should every version be separate package, or every major version, etc.
# 00:55:44 ghostbsdun Fortunately I have some background in algorithms =)
# 00:56:34 fenugrec if only it didn't take >1h to compile a toolchain, I'd probably have it solved already. Arg.
# 00:57:05 lundmar ghostbsdun: what is all that sudo nonsense you have in your readme? you should never build/run anything as root
# 00:57:24 lundmar fenugrec: hehe, I have the same problem - laptop is so slow ;)
# 00:57:51 lundmar fenugrec: maybe skip the c++ step for sh debug ;)
# 00:57:53 ghostbsdun Yes, readme is just a prototype too. It doesn't cover build process anyway
# 00:58:30 lundmar ghostbsdun: you have a long way ahead of you he he
# 00:58:46 ghostbsdun I've just started two weeks ago =)
# 00:59:11 lundmar good luck ;)
# 00:59:24 lundmar fenugrec: I see sh4 fails the same way.
# 01:01:00 ghostbsdun Maybe I can even replace all my stuff except virtual file systems with your. Your looks suitable
# 01:03:07 ghostbsdun lundmar, which of the repositories is the most suitable for desktop?
# 01:08:43 lundmar ghostbsdun: actually, there are two ways to go about you mission using buildgear. One is to create a set of "native" buildfiles from scratch. The other would be to simply use the "cross" buildfiles by specifying the HOST sys to be the same as the BUILD sys.
# 01:11:48 lundmar fenugrec: if you find anything interesting and don't resolve it please put your finding on your issue on github
# 01:12:44 fenugrec CLFS is an insane amount of work. Tried once ~ 2007
# 01:14:14 lundmar hehe I agree
# 01:35:51 fenugrec quits : Read error: Connection timed out
# 01:37:13 fenugrec joins #crosstool-ng
# 02:27:04 lundmar quits : Quit: WeeChat 1.4
# 02:32:12 fenugrec damn it, another kernel crash while compiling
# 02:41:17 blueness quits : Quit: blueness
# 03:11:49 ghostbsdun quits : Remote host closed the connection
# 03:13:23 blueness joins #crosstool-ng
# 03:57:32 fenugrec quits : Ping timeout: 244 seconds
# 04:12:10 blueness quits : Quit: blueness
# 04:36:15 blueness joins #crosstool-ng
# 05:52:30 diorcety joins #crosstool-ng
# 06:16:56 diorcety quits : Read error: Connection reset by peer
# 08:06:09 ragedragon joins #crosstool-ng
# 08:36:07 lundmar joins #crosstool-ng
# 09:38:58 florolf joins #crosstool-ng
# 09:38:59 florolf hi
# 09:40:59 florolf i'm trying to build a ppc32 (BE) toolchain for building uboot, which needs a libgcc built with -mrelocatable (or possibly, -mrelocatable-lib). is there a correct way to do this with crosstool-ng? (i've resorted to manually patching the final-stage gcc makefiles for the moment)
# 09:49:01 blueness quits : Quit: blueness
# 09:56:00 blueness joins #crosstool-ng
# 09:58:37 blueness quits : Client Quit
# 10:00:38 blueness joins #crosstool-ng
# 10:01:03 luc4 quits : Ping timeout: 240 seconds
# 10:34:57 luc4 joins #crosstool-ng
# 10:35:10 luc4 quits : Client Quit
# 11:12:48 alan_o quits : Ping timeout: 272 seconds
# 11:25:27 alan_o joins #crosstool-ng
# 11:35:02 fenugrec joins #crosstool-ng
# 11:40:32 Net147 quits : Quit: Quit
# 11:43:31 Net147 joins #crosstool-ng
# 13:18:00 ragedragon quits : Ping timeout: 260 seconds
# 13:35:39 ghostbsdun joins #crosstool-ng
# 14:05:16 luc4 joins #crosstool-ng
# 14:51:13 luc4_ joins #crosstool-ng
# 14:51:20 luc4 quits : Ping timeout: 260 seconds
# 14:51:20 luc4_ is now known as: luc4
# 16:00:52 lundmar ghostbsdun: here you go: https://github.com/mini-distribution/x86board
# 16:01:14 lundmar ghostbsdun: had a little trouble with ct-ng config to make it work for x86 but it is fine now.
# 16:03:58 ghostbsdun lundmar, hello. Thank you. Will look later
# 16:04:26 lundmar ghostbsdun: sure, its just for test so you can see how it works and what the meta is for x86.
# 16:05:12 lundmar I wish I had a faster computer, building toolchains takes so long when you have to iterate
# 16:08:25 luc4 quits : Quit: luc4
# 16:28:09 y_morin joins #crosstool-ng
# 17:41:54 enunes joins #crosstool-ng
# 17:51:51 JakeSays so to do this fabled canadian build, i need three toolchains? native, build -> target-host and build -> target-target?
# 18:01:06 lundmar JakeSays: basically yes, exactly as described in the 3 last steps here: http://crosstool-ng.org/#canadian_build
# 18:04:28 JakeSays lundmar: just wanted to make sure i read that right
# 18:05:35 lundmar its a triple whammy
# 18:07:18 JakeSays lundmar: its a disk space hog. lol
# 18:07:52 lundmar true, not to mention all the heat generated by your poor cpu to get there ;)
# 18:08:15 JakeSays lol
# 18:08:18 lundmar building toolchains is hard work for cpus ^^
# 18:08:33 JakeSays i have a large air conditioner in my office
# 18:08:41 JakeSays to cool my cpu and my machine's cpu
# 18:09:51 lundmar one of those new 10 core i7 would do nicely though for building stuff
# 18:09:59 JakeSays yes it would
# 18:10:09 JakeSays need a few more side projects for one of those tho
# 18:12:28 lundmar jez, it's only 140W TDP haha
# 18:12:52 lundmar better turn off all heating in the house before running that
# 18:31:48 lundmar fenugrec: updated the sh3 issue
# 18:33:34 fenugrec lundmar: hi - thanks, I also fiiinally managed to compile last night for sh3eb. It was too late to test though, I'll get back at it later today
# 18:34:03 lundmar fenugrec: you are the guy with hw so you will know for sure ;)
# 18:34:23 fenugrec yeah just looking at the disassembly will be enough
# 18:35:01 lundmar sh ISA, bzzzzzzz
# 18:35:14 fenugrec bzz ?
# 18:35:16 lundmar I wouldn't touch it ^^
# 18:35:36 lundmar It makes my brain go spaz
# 18:35:45 fenugrec what ? nah, I've come to like the SH instruction set quite a lot compared to, say, ARM
# 18:36:25 lundmar I've stopped venturing into other/old ISA - arm is superior :)
# 18:38:17 fenugrec lundmar: I happened on this a few months ago looking for some SH info - http://0pf.org/j-core.html - some people obviously find SH still relevant
# 18:38:59 fenugrec If nothing else, it's so much less messy than ARM. "oh do I need interworking ? does this support thumb ? 7TDMI ? 9 ? Cortex-M0 with a limited Thumb subset ? " etc etc
# 18:39:41 lundmar yes, it is interesting that sh is now so old the IP is expiring and allowing for stuff like open J core.
# 18:40:17 fenugrec but anyway, I didn't really choose SH, it's the hardware I'm working on that dictated it P-)
# 18:40:19 fenugrec heh
# 18:41:04 lundmar fenugrec: I figure that much ;)
# 18:41:30 lundmar obviously if you had to choose you would choose ARM - all sane persons do ^^
# 18:41:34 fenugrec it could've been worse, like some antique 68k variant, or V850, or other "oddball" stuff
# 18:41:36 fenugrec HAH
# 18:42:29 fenugrec maybe I got stockholmed into liking SH, but it's the truth, I enjoy working with that arch
# 18:42:35 lundmar don't diz m68k - it is excellent, I mean simple :)
# 18:43:05 fenugrec or Z80, or 8051 which I also won't touch gladly
# 18:43:06 lundmar well, at least SH is RISC type - that is good.
# 18:43:30 lundmar worst ISA is x86 - so much horrible legacy stuff
# 18:44:47 fenugrec yea. And a neat trick : these mcus often map the RAM at the top of the 32-bit space. To load absolute addresses, you can load a 16-bit immediate value that will get sign-extended to the desired RAM address which is usually > FFFF 0000
# 18:45:28 lundmar lots of trickery he he
# 18:46:25 fenugrec there's worse though. Like "mov r0, 0xF8", "r0 << 8", then you get "FFFF F800" . But that's devious
# 18:47:16 lundmar no, sh is too tricky for me :)
# 18:47:23 fenugrec (looking at your ct-ng tree... so *that's* where you're supposed to put the patches - I couldn't figure it out, so I butchered the file manually !)
# 18:47:33 lundmar haha
# 18:48:15 lundmar well, I thought that might be the case so I published the patch.
# 18:49:06 lundmar if you like, you can make a proper patch which also patches some of the older newlibs and send it upstream ;)
# 18:51:24 fenugrec I'm considering writing to the newlib dev mailing list for that
# 18:51:41 fenugrec but before I do, some testing needs to happen
# 18:52:09 lundmar good idea - have the newlib guys review it
# 18:52:55 fenugrec I'm still fuzzy on how everything fits together, i.e. gcc was compiled for "sh3" but it should normally hopefully also support backwards-compatible sh1, sh2, sh2e etc stuff. But the toolchain is named "sh3eb" anyway
# 18:53:46 lundmar you are saying it automatically changes to sh3eb?
# 18:53:56 fenugrec it's the same situation with "arm" I guess, the typical "arm" toolchains supports a lot of -mXYZ variants
# 18:55:41 fenugrec well, I mean that when configuring ct-ng, I had to choose sh3, and big-endian. In reality I want a general SH toolchain, like you'd have on ARM. But the tuple / triplet starts with "sh3eb-", and I'm not sure what implications that would have (not the naming per se, but my choosing "sh3" and big-endian)
# 18:59:23 lundmar fenugrec: you sh target is BE?
# 18:59:58 fenugrec yes
# 19:00:01 lundmar oh I see, it is BE
# 19:01:02 lundmar I'm building a sh3, BE now
# 19:01:28 lundmar curious to see where it changes to sh3eb because it shouldn't
# 19:03:16 fenugrec ct-ng does that somewhere, I think I saw it in... uh..
# 19:04:28 fenugrec scripts/functions
# 19:04:56 fenugrec wait, no
# 19:05:28 lundmar it is probably okay, it *eb seems to be commonly used notation for BE sh toolchains.
# 19:05:43 fenugrec scripts/build/arch/sh.sh, it uses the "target_endian_eb" specifically. Interesting.
# 19:06:11 fenugrec oh yea, and there's a gcc option for specifying endianness anyway, so I'm not sure why it needs to be defined for the whole toolchain
# 19:06:19 fenugrec for libc perhaps ?
# 19:07:14 lundmar it's mainly for configure scripts etc.
# 19:07:28 lundmar to identify which configuration to use
# 19:08:23 lundmar so it will work fine
# 19:12:45 aneyman__ y_morin: 383? :)
# 19:14:23 fenugrec but man. "building a cross-compiler is not trivial" is quite an understatement
# 19:20:10 lundmar true, it's basically a combination game of many options. ct-ng helps alot getting it right ;)
# 20:46:43 JakeSays ct-ng makes it sane
# 20:46:55 JakeSays still painful, but at least sane
# 20:52:45 lundmar man must hold on to his sanity
# 21:48:35 blueness quits : Quit: blueness
# 22:29:31 y_morin quits : Quit: Nighty Night!
# 22:29:58 lundmar quits : Quit: WeeChat 1.4
# 22:30:22 blueness joins #crosstool-ng
# 22:30:52 blueness quits : Client Quit
# 22:43:08 blueness joins #crosstool-ng
# 23:20:47 luc4 joins #crosstool-ng

Generated by ibotlog2html by Yann E. MORIN