| # 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 |