search

ghaerr / elks

Embeddable Linux Kernel Subset - Linux for 8086
Other
1.02k stars 108 forks source link

Building ELKS on macOS #1630

Closed Vutshi closed 1 year ago

Vutshi commented 1 year ago

Description

Configuration

ghaerr commented 1 year ago

Hi @Vutshi,

Are you trying to build the toolchain? For that, use tools/build.sh. ./build.sh is only used by the GitHub Continuous Integration. See if that helps.

ghaerr commented 1 year ago

Hi @Vutshi,

I see that ./build.sh calls tools/build.sh so my comment above probably won't help. I don't see this error on my system, but I'm running clang 11.0.0. The error is occurring in the emu86 build, and @tkchia will have to look at it. Since emu86 isn't required, you should be able to just comment out that line or assign l = 0 for the time being and hopefully the build will complete and you'll be able to compile all of ELKS afterwards.

ghaerr commented 1 year ago

Hello @Vutshi, hello @tkchia,

The error is occurring in the emu86 build, and @tkchia will have to look at it.

Oops - I mixed up elksemu which @tkchia maintains and emu86, sorry.

@Vutshi, try applying this patch to cross/build/emu86/rompcxt.c:

diff --git a/rom-pcxtat.c b/rom-pcxtat.c
index d2801cf..0c7810a 100644
--- a/rom-pcxtat.c
+++ b/rom-pcxtat.c
@@ -320,14 +320,12 @@ static int readwrite_sector (byte_t drive, int wflag, unsigned long lba,
        while (1)
                {
                ssize_t l;
-               ssize_t (*op)();

                off_t o = lseek (dp->fd, lba * SECTOR_SIZE, SEEK_SET);
                if (o == -1) break;

-               op = read;
-               if (wflag) op = write;
-               l = (*op) (dp->fd, mem_get_addr (addr_seg_off (seg, off)), SECTOR_SIZE);
+               if (wflag) l = write(dp->fd, mem_get_addr (addr_seg_off (seg, off)), SECTOR_SIZE);
+               else l = read(dp->fd, mem_get_addr (addr_seg_off (seg, off)), SECTOR_SIZE);
                if (l != SECTOR_SIZE) break;

                // success

Thank you!

Vutshi commented 1 year ago

Thank you @ghaerr, this patch worked for me. At least the the code has compiled. Now I am stuck at a more familiar place described already here https://github.com/jbruchon/elks/issues/1601#issuecomment-1560257664

Press ENTER to continue...
/Users/x2241064/Install/8088/ELKS/elks_last/Make.defs:10: ELKS is not configured yet
/Library/Developer/CommandLineTools/usr/bin/make -C config all
/Library/Developer/CommandLineTools/usr/bin/make -C lxdialog all
find: /lib/: No such file or directory
find: /lib64/: No such file or directory
find: /usr/lib64/: No such file or directory
find: /usr/local/lib64/: No such file or directory
-e 
>> Unable to find the Ncurses libraries.
>>
>> You must have Ncurses installed in order
>> to use 'make menuconfig'

make[2]: *** [local-curses.h] Error 1
make[1]: *** [all] Error 2
make: *** [kconfig] Error 2
Build script has terminated with error 2

I ran the following commands which you suggested in the old comment:

pkg-config ncurses --libs
-lncurses
pkg-config ncurses --cflags

I have a clean reinstall of homebrew which seems to contain the necessary stuff:

brew list
==> Formulae
bison           libevent        midnight-commander  texinfo
ca-certificates     libidn2         ncurses         tor
flex            libpng          openssl@3       wget
gettext         libscrypt       pcre2
glib            libssh2         pkg-config
htop            libunistring        s-lang
ghaerr commented 1 year ago

@Vutshi, lets get this problem finally solved. Can you manually check and find where libncurses is actually installed? One of the following should do it:

pkg-config ncurses --libs-only-L
(on my system, this displays a blank line)

or

cd /usr; find . | grep ncurses
(on my system, this finally displays the library as being in /usr/lib/libncurses.5.dylib)

On my macOS system, even though brew list shows ncurses, the library is found as /usr/lib/libncurses.5.dylib.

I notice in #1601 you said you've got 3 versions installed. The build for menuconfig seems kind of screwed up, but this can probably be most easily fixed for v0.7.0 by just adding the location of the library (as shown in https://github.com/jbruchon/elks/issues/1601#issuecomment-1560257664). If we can find the directory lib curses lives in, we can add that directory to line 64 of ~elks/config/lxdialog/Makefile.

Vutshi commented 1 year ago

@ghaerr finally the library works!

The ncurses library (and others) was relocated by Apple a couple of macOS versions ago to a new place:

/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/

But we are not there yet. Here is a new error:

Forcing filesystem check on /Users/x2241064/Install/8088/ELKS/elks_last/image/hd.img.

   363 inodes used (17%)
  2100 zones used (6%)

   294 regular files
    16 directories
    27 character device files
    22 block device files
     0 links
     4 symbolic links
------
   363 files
mfs /Users/x2241064/Install/8088/ELKS/elks_last/image/hd.img stat
image 1K blocks: boot 1, super 1, inodemap 1, filemap 4, inode 64, data 31681
inodes inuse 363, free 1684, overhead 1, total 2048
blocks inuse 2029, free 29652, overhead 71, total 31752
/Library/Developer/CommandLineTools/usr/bin/make -C elksemu PREFIX='/Users/x2241064/Install/8088/ELKS/elks_last/cross' elksemu
cc -O    -c -o elks.o elks.c
elks.c:27:10: fatal error: 'asm/ldt.h' file not found
#include <asm/ldt.h>
         ^~~~~~~~~~~
1 error generated.
make[1]: *** [elks.o] Error 1
make: *** [all] Error 2
Build script has terminated with error 5
tkchia commented 1 year ago

Hello @Vutshi,

That is a header file used in the elksemu subproject. I ported it from an earlier Linux/i386 version to Linux/x86-64 a few years back.

The code for elksemu is still extremely specific to Linux/i386 and Linux/x86-64. It should really be replaced with something less OS-specific.

Thank you!

ghaerr commented 1 year ago

@Vutshi,

The ncurses library (and others) was relocated by Apple a couple of macOS versions ago to a new place: /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/

What did you do, add that line in to the config/lxdialog/Makefile? Should I produce a PR to fix this? Admittedly, that particular location is quite system-specific and is not the brew version. It might be nice to find/use that one. Please advise!

cc -O -c -o elks.o elks.c elks.c:27:10: fatal error: 'asm/ldt.h' file not found

include <asm/ldt.h>

^~~ 1 error generated.

As @tkchia mentioned, that line is produced building the elksemu project, which will not compile under macOS. The good news is that it's built last, so you can consider your macOS ELKS development environment as working. I see that line as the last line of my tools build every time as well :)

Thank you!

tkchia commented 1 year ago

Hello @ghaerr,

By the way, do you think you might want to replace elksemu with something else, e.g. your Blink16 implementation?

Thank you!

ghaerr commented 1 year ago

Hello @tkchia,

do you think you might want to replace elksemu with something else, e.g. your Blink16 implementation?

In your opinion, is blink16 preferable to elksemu for debugging at this point? blink16 still doesn't support all the user-mode system calls like elksemu does, although blink16 works well for kernel tracing. I've never been able to build or run elksemu since I'm not running Linux. One option would be to (temporarily?) remove elksemu from the tools build, another would be to replace it with blink16. Or perhaps place links to both projects on the main and development pages. Also, our link to the original emu86 is outdated (and the CI fails on the SDL build of the same). I have been thinking of pointing to my fork of that, since I had added kernel symbol table support to it (although that was a couple years ago at this point).

I'm OK with the idea of removing elksemu from the tools build, since it produces an error which is confusing (or at least accept a PR that only builds it on Linux). Frankly, we may not want the dependencies and implied maintenance to have to be building 2 or 3 different emulators in the ELKS build, and I'd also be OK with just pointing to the various emulators/debuggers in a BUILD.md readme, and discussing additional options for developers there.

What are your thoughts on this, with regards to changes made before v0.7.0?

Thank you!

Vutshi commented 1 year ago

@ghaerr

What did you do, add that line in to the config/lxdialog/Makefile? Should I produce a PR to fix this? Admittedly, that particular location is quite system-specific and is not the brew version. It might be nice to find/use that one. Please advise!

Yes, I added that path to line 64 of ~elks/config/lxdialog/Makefile. There is likely a more universal and improved way to handle this new library location, as it appears Apple moved all of them there some time ago. This is what I have in this folder related to ncurses

ls /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/libncurs*   
/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/libncurses.5.4.tbd
/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/libncurses.5.tbd
/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/libncurses.tbd

I found this explanation in macOS Big Sur 11.0.1 Release Notes which I don't really understand:

New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)

=======

The good news is that it's built last, so you can consider your macOS ELKS development environment as working. I see that line as the last line of my tools build every time as well :)

Hurrah!!!

ghaerr commented 1 year ago

@Vutshi,

I added that path to line 64 of ~elks/config/lxdialog/Makefile.

/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib

Although its a total kluge, I will add the above path to config/lxdialog/Makefile, so that at least ELKS can build on up-to-date macOS systems. Regarding the other more complex dlopen suggestion Apple is making, that will have to wait until after v0.7.0.

Hurrah!!!

Yes!! Hopefully you can give me a thumbs up or down soon on whether we should hold the v0.7.0 release for your figuring out the CHS issues discussed in #1619.

Thank you!

Vutshi commented 1 year ago

@Vutshi,

@ghaerr

Although its a total kluge, I will add the above path to config/lxdialog/Makefile, so that at least ELKS can build on up-to-date macOS systems. Regarding the other more complex dlopen suggestion Apple is making, that will have to wait until after v0.7.0.

Maybe it is better to wait until after v0.7.0 because this piece of path MacOSX13.3.sdk will likely change already next month.

Yes!! Hopefully you can give me a thumbs up or down soon on whether we should hold the v0.7.0 release for your figuring out the CHS issues discussed in https://github.com/jbruchon/elks/issues/1619.

Very soon we will find out what is the problem there. I suspect bad CF cards.

ghaerr commented 1 year ago

Closed as completed via #1634.