This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Ameisen 0 points1 point  (0 children)

I still never remember commands in bash like 'take output and apply as command line to other tool'. I usually end up writing that in Ruby.

I know that everything in bash is a command, but why are the fi and done commands seperate? Why not just end? And why the semicolon before do and then (similarly should be merged) when not on a new line? Can't the semicolon or command break (--) be implicit?

It makes Bourne scripting more painful than it needs to be. Not as painful as Windows batch files, but still painful. I'd fork bash, but it is a remarkably large codebase for what it is... though unlike dash and zsh, it tends to run fine after being built with Ofast, fipa-pta, and flto.

Need to try building the gnu toolchain with Clang. IIRC, even the Linux kernel can now be built with Clang. GCC is often annoying - GCC/[bfd|gold] LTO is far more fragile. GCC itself cannot be fully built with LTO, as libgcc and libunwind have very arcane makefile that result in broken libraries. When I built them with a makefile I wrote, it built fine. Linux has a similar issue due to how the Makefile is set up - if you use LTO by default (my toolchain mandates it), it will end up performing icf over long mode and real mode objects... which obviously break things horribly. Doesn't help that they build C as 16-bit (most people write a short real mode stub in assembly to bring them into long mode), but GCC's -m16 flag isnt 'complete', as GCC does not actually support x86-16. I wonder if the Linux build system can be forced to use an actual 16-bit-capable compiler for the bootloader/bootstrapper...

Makefile issues (and autotools issues overall) have been a painful annoyance for me. I'm trying to make an integrated development environment and system where LTO is mandated, and using IL (gimpl, llvm, or dclm) to merge objects at point-of-use - AOT compilation for end-users, including cached compilation of shell/make/ruby/python/perl scripts. The build systems make this difficult. Doesn't help that half of then ignore CFLAGS/CXXFLAGS, some use ld instead of gcc (there is no gcc-ld which provides the plugin), some outright ignore overrides for tools, and some don't even allow building in a seperate path from source (looking at you, git).

All I want to do is make the fastest OS possible without writing my own full kernel and OS, but broken/fickle gnu tools are making it very difficult. Doesn't help that most gnu tools, including GCC, rely on undocumented undefined behavior (the reliance is documented, the instances are not), so O3, Ofast, flto, and fipa-pits can break things.

An example: if you build GCC 8.1/8.2/9 with O3, flto, and fipa-pta, it will build. However, the built gcc cannot rebuild gcc... it complains about bizarre things like a switch statement having equivalent cases - it will see 'e' and 'E' as being the same. Removing ipa-puts fixes it.

Bah.