[openbeos] Re: building obos

On 2005-02-27 at 16:41:43 [+0100], Daniel Furrer wrote:
> 
> Ok, it turns out I was not using the updated gcc and it seems that the
> gensyscallsinfos, compiled with the old gcc just doesn't do anything, no
> matter what the arguments are, etc.
> So far so good. No happy end, though :)
> 
> There are now two other places, where it hangs:
> On Zeta:
> ...patience...
> don't know how to make
> ./distro/x86.R1/beos/system/add-ons/kernel/drivers/dev/tty
> don't know how to make
> ./distro/x86.R1/beos/system/add-ons/kernel/drivers/dev/console
> don't know how to make
> ./distro/x86.R1/beos/system/add-ons/kernel/console/vga_text
> ...found 4923 target(s)...
> ...can't find 3 target(s)...
> ...can't make 1 target(s)...
> ...skipped config.x86.ini for lack of
> ./distro/x86.R1/beos/system/add-ons/kernel/drivers/dev/tty...
> ...skipped 1 target(s)...
> 
> I think it's getting somewhere here...

It looks like this mechanism doesn't get the dependencies right. You can try 
building the three files manually first:

  jam -q '<driver>tty' console vga_text

The build system could be fixed in this respect, but it looks like more work 
than I would think it deserves. IMHO the boot floppy method is outdated and 
should better be removed alltogether. Noone has tested it for a while, so 
even if you can build a boot floppy, it might not work.

Under BeOS/Zeta I would recommend to build a HD image instead. I'm using this 
method and so do other developers. It is supposed to work and unlike a boot 
floppy tells you better what our current state is.

> On Linux, however it doesn't even get to that point but already aborts with
> the following messages:
> 
> assimil8or@debian:~/Haiku/current$ jam -q config.x86.ini
> ...patience...
> don't know how to make
> ./distro/x86.R1/beos/system/add-ons/kernel/drivers/dev/tty
> don't know how to make
> ./distro/x86.R1/beos/system/add-ons/kernel/drivers/dev/console
> don't know how to make
> ./distro/x86.R1/beos/system/add-ons/kernel/console/vga_text
> ...found 1887 target(s)...
> ...updating 7 target(s)...
> ...can't find 3 target(s)...
> ...can't make 1 target(s)...
> KernelLd
> objects/x86.R1/kernel/kernel
> objects/x86.R1/kernel/core/disk_device_manager/kernel_disk_device_manager.o(
> .text+0xb498):
> In function `BPrivate::DiskDevice::KDiskDeviceManager::FindFileDevice(char
> const*)':
> : undefined reference to
> `__dynamic_cast'
[...]
> 
> ...failed KernelLd objects/x86.R1/kernel/kernel ...
> ...skipped config.x86.ini for lack of kernel...
> ...failed updating 1 target(s)...
> ...skipped 1 target(s)...
> 
> From what I read elsewhere this sounds like a c++ file being compiled with
> gcc instead of g++.

That's right, but that's OK as long as one links against the respective 
libraries. With gcc 2.95.3 this is just libgcc.a, but newer compilers have 
apparently moved the C++ support into separate libs (off the top of my head: 
libgcc_eh.a (or libgcc_eh_frame.a or something like this), and libsupc++.a). 
You can try to add those libs to the libraries the kernel links against 
(src/kernel/Jamfile). I did that a while ago and found out that one symbol 
remains missing, a Linux specific dependency to libc. In case of the kernel 
this function should not be used anyway, so one could have added an empty 
implementation, but for userland apps things look different, so I stopped 
trying at that point.

When I'm done with implementing userland debugging support, I may give 
supporting building under Linux another thought. It would be really nice, 
since building under Linux is amazingly fast compared with BeOS, but this is 
really going to be quite a bit of work.

CU, Ingo

Other related posts: