[openbeos] Re: building obos
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 27 Feb 2005 17:44:47 +0100
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:
