I have looked at all the makefile-engines for Alpha 1, 2, 3 and 4. And found those drivers were added in all versions of the makefile-engine.
I am now going to install Alpha 1 and see what happens when I try to compile the same code.
Which added “drivers” are you talking about ?!
You mean libs ?
Neither /boot/system/lib/libroot.so nor /boot/system/lib/libbe.so used by makefile-engine. It lists libsupc++.so but as STDCPPLIB. I had no time to check if it is added or not.
Is it possible, that you opened your Makefile with Palladain and it changed automatically the libs? It can do it, AFAIK.
I tried installing Alpha1 one on my laptop but it does not boot. This is driving me crazy.
Sorry, my mistake. I should have said libraries.
Anyway I got Alpha1 installed on my desktop and compiled the criver there, so today I am going to look and see if I can find the difference.
Give me a few hours.
I am going crazy, I looked at how the Alpha1 compiled the driver and then used that information to compile it on Alpha4, the driver did compile but I still get “bad data” in the syslog. Can anyone tell me what I am doing wrong.?
Below is the CLI commands I tried:
mkdir objects > /dev/null 2>&1;
mkdepend -I./ -p .c:objects/%n.o -m -f “objects/xxxx.d” xxxx.c
cc -c xxxx.c -iquote. -D_KERNEL_MODE=1 -fPIC -O0 -w -o “objects/xxxx.o”
cc -o “objects/xxxx” objects/xxxx.o -nostdlib /boot/system/develop/lib/KERNEL /boot/system/develop/lib/haiku_version_glue.o -L./
xres -o objects.x86-gcc2-release/xxxx
mimeset -f “objects/xxxx”
This seems to compile the driver okay, but if I put the driver in non-package bin and supply a link to dev directory I still get a failure.
Syslog still says when I boot it:
KERN: Could not load kernel add-on “/boot/home/config/non-packaged/add-ons/kernel/drivers/xxxx”: Bad data
KERN: load_module_image(/boot/home/config/non-packaged/add-ons/kernel/drivers/xxxx) failed: Bad data
KERN: Could not load kernel add-on “/boot/home/config/non-packaged/add-ons/kernel/drivers/xxxx”: Bad data
KERN: load_module_image(/boot/home/config/non-packaged/add-ons/kernel/drivers/xxxx) failed: Bad data
KERN: Could not load kernel add-on “/boot/home/config/non-packaged/add-ons/kernel/drivers/xxxx”: Bad data
KERN: load_module_image(/boot/home/config/non-packaged/add-ons/kernel/drivers/xxxx) failed: Bad data
I know I am doing something wrong, but I can’t figure out what.
PS. the flag -no-fpic does not work, it demands I use -fPIC
Maybe some other requirement isn’t being met. Is the table of driver function calls the same, or did some new ones get added? Are the critical ones not NULL? Maybe start out with some existing driver code and modify it.
I did use code that should work. I took the zero.c code that was in the kernel add-ons in the Haiku source code, changed the name to xxxx.c and used StyleEdit to change all the text “zero” to “xxxx”.
I also copied the makefile-engine to root and changed the Makefile to point to it.
So the driver I am trying to compile looks like the zero.c with just the text changed.
I tried to include my code for you to see but the editor messed the include and comment lines up.
Should I move this to the development mailing list?
Whoa, slow down there and just try to get zero.c to compile first. Start by seeing what it does with jam. Use “jam -q -dax zero” in the source directory with zero.c (assuming you already ran …/configure in the “generated” directory). I get this (after 805 other things compile, including the kernel):
gcc -O2 -Wall -Wno-trigraphs -Wmissing-prototypes -Wno-multichar -Werror -nostdinc -nostdinc -finline -fno-builtin -march=pentium -c “zero.c” -D_KERNEL_MODE -DARCH_x86 -DB_USE_BUILTIN_ATOMIC_FUNCTIONS -D_BEOS_R5_COMPATIBLE_ -DBOOT_ARCHIVE_IMAGE_OFFSET=320 -D__HAIKU_PRIMARY_PACKAGING_ARCH=“x86_gcc2” -DHAIKU_DISTRO_COMPATIBILITY_DEFAULT -DHAIKU_INCLUDE_PATENTED_CODE=0 -DHAIKU_TARGET_PLATFORM_HAIKU -DHAIKU_REGULAR_BUILD -I…/…/…/…/…/build/user_config_headers [zillions more headers here] -o “…/…/…/…/…/generated/objects/haiku/x86_gcc2/release/add-ons/kernel/drivers/common/zero.o”
Then it links it with:
gcc -shared -nostdlib -Xlinker --no-undefined -Xlinker -soname=“zero” -o “…/…/…/…/…/generated/objects/haiku/x86_gcc2/release/add-ons/kernel/drivers/common/zero” “/packages/gcc-2.95.3_2017_07_20-1/.self/develop/tools/lib/gcc-lib/i586-pc-haiku/2.95.3-haiku-2017_07_20/crtbeginS.o” “…/…/…/…/…/generated/objects/haiku/x86_gcc2/release/system/glue/haiku_version_glue.o” “…/…/…/…/…/generated/objects/haiku/x86_gcc2/release/add-ons/kernel/drivers/common/zero.o”
“…/…/…/…/…/generated/objects/haiku/x86_gcc2/release/system/kernel/kernel.so” “…/…/…/…/…/generated/build_packages/gcc_syslibs_devel-2.95.3_2017_07_20-1-x86_gcc2/develop/lib/libgcc.a” “/packages/gcc-2.95.3_2017_07_20-1/.self/develop/tools/lib/gcc-lib/i586-pc-haiku/2.95.3-haiku-2017_07_20/crtendS.o”
Then there’s a bunch of version setting, mime types, and a final chmod. Hopefully you can figure out the critical parts and recreate it in a makefile. Though I wonder about that D_BEOS_R5_COMPATIBLE_ define.
Hello! why the alpha? why not the nighty? i didnt catcha the idea of use the old aalpha, if you try the nigthys they are more stable and modern… it is better.
When I used the latest nightly the driver would not compile using the Makefile.
But when I installed the Alpha1 the Makefile worked fine.
I see x86_gcc2 mentioned, this is the 64 bit version of Haiku you are compile under?
I am trying to convert all my code to work on the x86_64 version of Haiku. So far the CLI version are converting fine, I am still trying the track-add-ons and hope to move to the GUI programs soon.
But first I need to figure out how to compile drivers to work on the 64 bit version of Haiku.
All the same I think I see some clue about what I have to change.
1 Like
I am just learning maybe it can get more direct help on the irc
Seems that our makefile-engine is not up-to-date then, as clearly it doesn’t link with crtbegin/endS.o
When looking at build/jam/KernelRules line 102+, there is this glue code but also some more link flags mixed in.
Give a look at build/jam/ArchitectureRules to see what’s set for x86_64. Depending on the gcc version, there is indeed extra flags which the makefile-engine don’t pass explicitly.
I am going to bite the bullet and see if I can get Jam to work, then use that to figure out how to compile drivers using the CLI commands and also using “make” with the “Makefile”…
Since it will be for compiling drivers for the 64 bit version of Haiku I will start a new forum thread once I get a good idea of where to go.
1 Like
I have started to read the ArchitectureRules — MY BRAIN HURTS!
Wish me luck.
1 Like
What did happen?
Apologies for the necrobump but I ran into this same issue and had to go looking for the answer. tl;dr - you need to add this to your linker args: -z max-page-size=4096
The linker aligns program headers to page boundaries. In the x86_64 builds that’s 2MB, which leads to stuff like this: 
The kernel addon loader doesn’t like that: https://git.haiku-os.org/haiku/tree/src/system/kernel/elf.cpp#n2250
2 Likes
Not many people compile device drivers out-of-tree, and most of them just use the makefile-engine if they do, which is probably why this was never properly documented 
Be warned that our kernel ABI is not that stable and we do break it, and a lot of important APIs (e.g. I/O scheduler integration) are really only usable from within the tree at the moment. If we had more time, we would probably sit down and hammer some of these rough spots out; but there really are not many people writing out-of-tree kernel code at the moment…
IIRC there is still a problem in makefile-engine on 64bit #15702 (makefile_engine: can't build 64bit drivers) – Haiku