change hello.mo building process, compile and link separately

[jg1uaa]

There is no problem to create hello.mo with default compiler on
Debian-9.5/amd64.

But building hello.mo with i386-elf-gcc (5.5.0) cross compiler on
OpenBSD-6.3/amd64, undefined reference to 'rt_kprintf' error occurs.

To avoid this error, "compile and link" process needs to be divided to
simply "compile" and "link".

On Debian-9.5, both previous and current method produces same hello.mo.

We have to improve disk image creation (Linux dependent),
this is a future homework.

[BernardXiong]

Why not use rtthread-apps?

[jg1uaa]

Simply testing default source code package.
Is this (bsp/x86) hello.c obsolete?

[BernardXiong]

Yes, you can setup M_CFLAGS/M_CXXFLAGS /M_LFLAGS in rtconfig.py and use rtthread-apps to build a dlmodule or dynamic library.

You can refer qemu-vexpress-a9 for more information.

And, the maintainer of x86, @parai , please use this way to build dlmodule.

[parai]

I think for x86:

1. need to bring up the menuconfig
2. fix some building errors
3. need a bootloader

For study purpose only, I didn't want to spent much time on that, so I integrate the rttthead x86 bsp to as x86, which I use the bootloader from Tinix to boot up the rtthread on qemu, that's a study project and the code is with a lot tricks to be compatible with both rtthread and the OS askar wrote by me.

I think not good to just push all the codes to rtt mainline as the coding style is not compatible with rtt and the code quality is not very good as I don't care as I just use that to do theory study.

[jg1uaa]

building with #define RT_USING_MODULE in rtconfig.h, there is link error related dlmodule_relocate. here is linker message

build/applications/application.o: In function components_init': applications/application.c:51: undefined reference to rt_system_module_init'
build/kernel/components/libc/libdl/dlelf.o: In function dlmodule_load_shared_object': /home/uaa/z/rt-thread/components/libc/libdl/dlelf.c:155: undefined reference to dlmodule_relocate'
/home/uaa/z/rt-thread/components/libc/libdl/dlelf.c:171: undefined reference to dlmodule_relocate' build/kernel/components/libc/libdl/dlelf.o: In function dlmodule_load_relocated_object':
/home/uaa/z/rt-thread/components/libc/libdl/dlelf.c:393: undefined reference to dlmodule_relocate' /home/uaa/z/rt-thread/components/libc/libdl/dlelf.c:400: undefined reference to dlmodule_relocate'
/home/uaa/z/rt-thread/components/libc/libdl/dlelf.c:406: undefined reference to dlmodule_relocate' build/kernel/components/libc/libdl/dlelf.o:/home/uaa/z/rt-thread/components/libc/libdl/dlelf.c:424: more undefined references to dlmodule_relocate' follow
ld: warning: creating a DT_TEXTREL in a shared object.

IMHO, we have to fix building error first. Building trouble makes many people disappointed. Configuration menu is the next.
I think bootloader is not required, qemu's -kernel option is good enough to test quickly. If someone want to run RT-Thread on real machine, creating GRUB boot disk by themselves.
But, there is no floppy disk drive on current PC, we have to implement RAM disk driver in the future.

[BernardXiong]

Yes, the boot loader is not required. Or, we can use grub to boot RT-Thread in QEMU or in real machine.

I will look at this BSP later (in this week) for scons, Kconfig, dlmodule etc.

[jg1uaa]

well do I have to close this pull request once, and do other work?

[parai]

@BernardXiong just suggestion, as now rtt support components init, I think we can create a general build solution which is almost the same as kernel. like:

under root of rtt
cp bsp/xxx/defconfig .config
scons --menuconifg
scons

[BernardXiong]

@parai No need.

RT-Thread will create a new wizard to create a new BSP based on supported boards. For scons, you can use scons --useconfig xxx_defconfig to apply the saved config and generate a new rtconfig.h.

[jg1uaa]

Even if components/libc/libdl/arch/x86.c fix applied, linker says:
applications/application.c:51: undefined reference to `rt_system_module_init'

[parai]

the name should be rt_system_dlmodule_init

[jg1uaa]

which should be fixed, dlmodule.c or other components?
I grep'ed rt_system_module, some components calls rt_system_module_init().

bsp/gkipc/armv6/rtos_lib.c: rt_system_module_init();
bsp/lm3s8962/applications/startup.c: rt_system_module_init();
bsp/mini2440/applications/startup.c: rt_system_module_init();
bsp/rx/applications/application.c: rt_system_module_init();
bsp/simulator/drivers/module_win32.c:int rt_system_module_init(void)
bsp/x86/applications/application.c: rt_system_module_init();

[BernardXiong]

These BSPs should be modified later.

[BernardXiong]

Wow, the libdl depends on libc. But there is no newlib in host gcc. How to resolve this issue?

[parai]

@BernardXiong I play some tricks to make it works, such as comments those build errors which I think will not affect the dlmodule feature.

generally I think you can try this compiler toolchain on windows: https://github.com/lordmilko/i686-elf-tools/releases/download/7.1.0/i686-elf-tools-windows.zip

below is a pic shows I use this toolchain to build out the rtthread with dlmodule and run the hello.mo with qemu.

[BernardXiong]

I use linux to build this x86 BSP.