Open spencerking opened 5 years ago
Maybe wrap the build in some docker/compose files?
Yeah I don't use Docker.
Maybe I'll document it in depth later but for now please just view Crystal and GCC's manual for required build dependencies.
In response to #15:
I never found out what package contains x86_64-elf-as, which is needed to build the kernel.
When trying to build binutils I get the following:
make[1]: *** [Makefile:849: all] Error 2
make[1]: Leaving directory '/home/spencerking/Documents/lilith/userspace/toolchain/binutils'
make: *** [Makefile:13: build_binutils] Error 2
If you're just building the kernel, you'll only need x86_64-elf binutils, GCC and Crystal; userspace/toolchain/binutils
is for userspace applications.
Building patched Crystal fails despite various attempts, probably due to different (and constantly updating) LLVM and Crystal versions. (Edit: I didn't make clean
after the initial build failed, screwing up future builds.)
@ffwff Could you tell us which version of LLVM and Crystal you're using to build this? I can't sleep I think I'm gonna cry
Edit: Compiler building works with LLVM 9.0.0 (installed with linuxbrew) + Crystal 0.32.1 (From crystal github releases)
Building the patched Crystal consistently works for me.
The bigger issue for me is it's really not clear what packages are required for the entirety of the build process (kernel, userspace, the whole deal). This is why I had originally mentioned creating a nix shell. Everyone would be using the same versions of the same packages, making this a non-issue.
I would definitely appreciate that, but I'm sadly not well acquainted at nix to approach that :( I'll at least try to document the process thoroughly after I get it to work :)
@Scorbie I would be happy to do it once I can actually build the project.
Okay, I got all the specified requirements ready. I can build the kernel (which doesn't run but that's a seperate issue AFAIK; origin/master is shaky, captain!)
@ffwff Present for your 1000th commit, the text below is yours. Congrats.
/usr/bin/crystal
)Edit(2020.11): Welp... I was careless and misread the instructions and this tripped me. Updating the instructions to be clearer (and hopefully more foolproof).
configure --prefix ... --target x86_64-elf && make && make install
in the first copyconfigure --prefix ... --target i686-elf && make && make install
in the other onemake distclean
doesn't allow you to reuse the same source directory.configure
, you have to
--prefix
if you have root (root is needed for make install
)/usr/local/bin
PATH="<prefix-path>:$PATH"
in your sh
startup script.
make
and make
launches sh
for executing commands.sh
has to see the tools in $PATH
, regardless of which shell you use.$ENV
variable;
export ENV=<sh-startup-script-path>
in your~/.profile
if it's not set
PATH="<prefix-path>:$PATH"
in your<sh-startup-script>
logout and login to make sure changes are applied.
$PATH
in ~/.profile
did work for some reason I don't understand.Of course git clone https://github.com/ffwff/lilith
and cd lilith
first.
Actually I'm just reiterating the pretty well documented readme, it just doesn't work It may not build when something screwed up in the process so good luck.
make toolchain/crystal/.build/crystal
cd toolchain/crystal
&& make clean
&& rm -rf ~/.cache/crystal
so that the patched Crystal is not littered with your past failed build artifacts.make build/kernel
Make sure to install bison
and flex
beforehand, then see my post below for instructions.
make run
- Qemu hangs with no disk found
but it runs, at least.make disk.img
=> make run_img
- Fails with error, will raise an issue if needed.I'll try with docker if there's much request (I haven't used docker much so it's quite time consuming)
@Scorbie I had to edit the Makefile to hardcode the paths to the binutils binaries on my system. Possibly a fish issue, but I don't know yet.
I have gotten the kernel to build, but when I try to make run
I get a black screen in qemu and an error in my terminal stating that no disk was found.
Edit: Nevermind, I see you ran into the same issue.
I'm busy at the moment, but I usually use this command for debugging:
make rungdb_img RELEASE=1
You can also pass NO_CPUEX=1
to trigger a breakpoint on CPU exceptions.
qemu-system-x86_64 -kernel build/kernel -monitor telnet:127.0.0.1:7777,server,nowait -m 512M -serial stdio -no-shutdown -no-reboot -vga std -cpu SandyBridge,+pdpe1gb -hda disk.img -S -gdb tcp::9000 &
sleep 0.1s && /usr/bin/gdb -quiet \
-ex 'target remote localhost:9000' \
-ex 'hb kmain' \
-ex 'continue' \
-ex 'disconnect' \
-ex 'set arch i386:x86-64:intel' \
-ex 'target remote localhost:9000' \
build/kernel64
qemu-system-x86_64: -hda disk.img: Could not open 'disk.img': No such file or directory
Reading symbols from build/kernel64...
localhost:9000: Connection timed out.
Hardware assisted breakpoint 1 at 0xffff808000124470: file /home/spencerking/Documents/lilith/src/main.cr, line 29.
The program is not being run.
You can't do that when your target is `exec'
The target architecture is assumed to be i386:x86-64:intel
localhost:9000: Connection timed out.
@spencerking You probably shouldn't hardcode the binutils path, but rather add them to "$PATH" as (edit) I mentioned in the post. Or did you mean that it couldn't find cross-binutils when you configured without setting --prefix
?
@ffwff Yep seems like you're busy. I'll try that after I get back home. Thanks.
@Scorbie I mean I added them to my path and make still isn't picking them up, but they work fine otherwise. I imagine it's fish (my default shell) not playing nice with make, but I haven't tested with anything else.
@spencerking Ah, strange indeed, I'm out of clues and can only random guess... Wait! make (if it's POSIX-compatible) by default invokes sh, not fish. So I think you should update the whatever-sh-source directory ~/.profile
(Updated my post above as well).
Edit 2020.11: Updated the post again for complete information, ping me if there's anything wrong.
I added additional build instructions (thanks @Scorbie!) Tell me what yall think.
Oh you said "tell"! Love it! Newbie friendly, on-topic, I think I can see you put in some thoughts there. Thanks.
Hopefully the last question from me on this one: Any idea what package contains grub-install? I'm not seeing it in dnf.
If you use a linux system, you should probably have it in /usr/sbin
. (Thus, in your path.)
Otherwise, I don't have any idea except from building from source (which should be possible, I hope)
@Scorbie Turns out grub2-install is not necessarily aliased as grub-install.
Eck, kudos to you for finding that out.
On Thu, Jan 2, 2020, 2:42 PM Spencer King notifications@github.com wrote:
@Scorbie https://github.com/Scorbie Turns out grub2-install is not necessarily aliased as grub-install.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ffwff/lilith/issues/2?email_source=notifications&email_token=ABZTKWOMDODQRGP5GXWS7JTQ3V5F3A5CNFSM4ISIKSJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5WENI#issuecomment-570122805, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZTKWK7U76RPPCKMC6FRADQ3V5F3ANCNFSM4ISIKSJA .
I'm only using legacy grub, grub2 is currently not supported.
You mean legacy multiboot? I think GRUB2 supports old multiboot just fine, guessing from the fact that GRUB 2.04 manual points to multiboot 0.6.96 spec. So no worries?
I'm only using legacy grub for the image's bootloader. I might be switching to grub2 at some point but it really isn't worth it (apart from maybe removing the i686-elf
toolchain for building bootstrap code).
I haven't tried using grub2 yet, however it should work if you load it from the multiboot command.
I see, thank you :)
Okay, I am building the userspace and the following words would be VERY helpful for others seeing the issue.
(BTW, assume every doc I write in this repo as Public Domain or CC0)
For this post, I'm assuming the working directory is <path-to-lilith-repo>/userspace/toolchain
flex
and bison
installed, in ADVANCE. (maybe texinfo
too)
syslex_wrap: missing syslex.c
that keeps haunting you whatever you do.rm -rf binutils
and run make again.
make clean
doesn't work if you didn't have flex or bison in the first place. (After googling, my guess is that this affects the configure stage)The build is still ongoing; Will update if there's any changes.
For people reading this issue thread, I documented my trial and error on another thread (...) https://github.com/ffwff/lilith/issues/22#issuecomment-570885520
- Yes, you really need to wipe the whole thing away.
- No,
make clean
doesn't work if you didn't have flex or bison in the first place. (After googling, my guess is that this affects the configure stage) I think you're totally right about the configure stage - I wasted a lot of time on this and your post helped tremendously. Thank you!
- Yes, you really need to wipe the whole thing away.
- No,
make clean
doesn't work if you didn't have flex or bison in the first place.
(After googling, my guess is that this affects the configure stage)I think you're totally right about the configure stage - I wasted a lot of time on this and your post helped tremendously. Thank you!
Thank you, I've updated the instructions to emphasize this once more.
I've found that a clean install of Fedora 30 is pretty lacking when it comes to building the project. I'm using this issue to document all of the packages I need to install as I work towards a build. Going forward it may make sense to create a nix or guix configuration, or perhaps split the custom components into their own repositories with clear documentation.
Packages: llvm-devel pcre-devel libevent-devel patch texinfo zlib-devel