Just came across this 
The selected debug format is not supported
yeah something like that I guess. Could be gdb now works… anyhow, of course for lldb I needed to do a few more fpcmake -r’s… recompiling…
update: nogo yet on that debugger. For GDB I don’t know what version I should have: when I start lazarus using gdb it tells me that we have wrong version in compilation unit header (is 4, should be 2). That sounds like gdb is too old and does not understand 4. we have version 6.3(?) and we would need 7.1(?), or at least a newer version.
Also when you startlazarus from the command line you see that the program to debug PID is supplied, only gdb does not pick it up. incompatible somehow?
UPDATE:
Looks like to old, it was discussed here before. gdb needs to be updated. did we do that already?
Trying to compile/use FPdebugger fails for me with too long arguments with ld during lazarus bigide recompile. Giving up on this part. Besides it seems to have very limited capabilities anyway.
I did see that some lazarus projects that are inside lazarus, amongst which some stuff for this debugger need installed windres from Haiku’s crosstools in home/config/non-packaged/bin/ (windows resource compiler) to make building them work.
Maybe that app should be installed alongside lazarus inside a package.
So I think I’ll conclude that debugging with lazarus on Haiku x64 is not possible at all. It only would work with a recent gdb, ours is too old (6.3). I did a brief try at compiling it but some magic is probably needed to make that happen on Haiku (it fails for me).
1 Like
There are a few “newer” recipes at haikuports, but they are disabled, probably for a good reason?
Same here 
EDIT on 32bit it does seem to work with bigide ?
I read somewhere that newer gdb works as in it reads symbols but fails to launch with the app to debug.
Still I’d like to confirm that this is indeed also the case for use inside Lazarus as that was probably never tried before. No idea if that would behave differently.
Also, I would say it should be fixed at some point. It would be a shame if that would stand in the way of Lazarus being used on haiku I think…
About too long arguments: I read that this can happen with file arguments with Asterix in case that unfolds to a very large number of files. Apparently that happens in the background before the target app is launched. The fix can be specifying a bit better sometimes. The other route would mean I guess there needs to be more memory reserved for this argument unfold action.
I have no clue how to fix this and I think this lies outside of the scope of things I can try.
1 Like
To use gdb with Haiku apps you need it to talk our custom debug protocol which is not what GDB uses on other platforms. If you don’t include these patches, you get a GDB that runs fine, but cannot be used on native applications, only for remote debugging (you can use the “target remote” command and connect to a linux machine and debug programs running there for example). So, it runs, but it’s completely useless for the main case you’d use it.
These patches were never updated to newer versions of gdb.
No, there is no magic with path involved in selecting the standard library to use. It looks like something in the freepascal toolchain is using the wrong linker (compiling with gcc-x86 and linking with old ld instead of ld-x86) or explicitly linking that library when it shouldn’t.
This has been the main problem with freepascal for years. It builds and runs fine when compiled with gcc2, but then it gets very confused when you try to link some libraries against gcc8. So we should make sure that all of freepascal is built with gcc8, and is correctly set up to pick libraries in the correct directories to make sure it always stays in the gcc8 world and does not pick some things from the gcc2 side.
4 Likes
I understand, makes sense. Do you have any hints about howto try to update gdb then and/or what one would encounter trouble wise?.
I guess the other route would be updating lazarus somehow to work with our own debugger.
BTW I can imagine that if Lazarus is compiled/configured correctly on GCC2, (Haiku 32bit) that gdb -would- work there, at least I assume in all my ignorance that the compilation unit headers will probably be version 2 or so then?
Yes, but you can’t build Qt with gcc2 so you would not get the UI running. Which limits things quite a bit for Lazarus, I guess.
Our current patch series for 6.3 has all the needed changes: haikuports/dev-util/gdb/patches/gdb-6.3.patch at master · haikuports/haikuports · GitHub
Waddlesplash has rebased this patch on top of gdb 8.1 here: haikuports/dev-util/gdb/patches/gdb-8.1.patch at master · haikuports/haikuports · GitHub but according to his commit message, this results in an use-after-free and he was not able to find exactly what was causing it. So, it looks like a good place to start, investigating this problem.
2 Likes
I can’t tell if the fpc_bin (bootstrap version for download) is build against gcc2 or not, trying to change some things in the recipe so it uses fpcmake before make (and skipping install/makepack), then in INSTALL() I’m trying to use the install preferences used by makefile.fpc, so things end up in $binDir and $ibDir instead of $prefix/bin and $prefix/lib …
OK tried to get haikuports running on my system x64. When I try to process gdb-8.1 it fails with a missing file in haikuports/repository: gdb_source-8.1.DependencyInfo. There are a lot of DependencyInfo files in that folder, but just not this one.
What could be wrong here I wonder?
Did you remove the “untested”/“broken” markers in the recipe? Remove the interrogation points here (or enable ALLOW_UNTESTED in your haikuports configuration if you want to build all unsupported things, probably a bad idea):
FreePascal & Lazarus can now use another debugger not GDB only.
1 Like
Thanks @jma_sp for the pointer. Reading that discussion shows though it still has limitations. Still it would be nice if it would work indeed.
Both @Begasus and I bumped into the ‘too long arguments’ problem trying to compile lazarus bigide or FPdebug(ger).
Would be -very- nice if that could be resolved, but it looks like at least we have no clue howto do that atm…
1 Like
Sorry, I don’t understand your remark about removing untested/unbroken. Also I don’t understand why you show a piece of the recipe with the ARCHITECTURES line highlighted.
Could you elaborate?
Please be aware this is the very first time ever I even look at haikuports/porter and recipes. The concept is even still a bit unclear to me.
Thanks!
Update: I assume you mean removing the ‘!’ and ‘?’ characters based upon looking at the 6.3 recipe… apparantly I need to install a lot of dependancies by hand (try gdb, fail, see message, install dependancy, retry, etc… I am guessing this can be done handier than this. I tried to find some docs online, but I failed in finding it.)
Ok so here is how “architectures” works: some recipes are marked as broken (with a !) or untested (with a ?) on some architectures. By default, haikuporter will ignore these and not try to build them. So if you want to work on one of these recipes to fix the problems, the first step is to remove this marker for the relevant architecture you are working with.
For dependencies, there are various switches to control what haikupoter should do. Usually you want --get-dependencies which will try to download them using pkgman. This is not the default because currently the dependencies downloaded this way are added to your /boot/system/packages, and modifying the running OS without explicit confirmation from the user would be bad practice. Ideally, the packages would be downloaded somewhere else by haikuporter, and then we can make this option the default.
The documentation is in the form of a github wiki: Home · haikuports/haikuports Wiki · GitHub
Documentation for ARCHITECTURES: HaikuPorter BuildRecipes · haikuports/haikuports Wiki · GitHub
The documentation for command line options (including --get-dependencies) is in the --help output of haikuproter.
1 Like
Is it possible to allow build everything even if it is not mentioned at all in supported architectures (riscv64 for example)? Currently I use HaikuPorter code hack that permit riscv64 build for all non-“any” architecture packages.
I don’t know what the default is for architectures that are not listed in the recipe. If the default is “untested”, then you could set allow_untested=yes in haikuports.conf. If the default is something else, we should probably change it, because “untested” seems to be a reasonable default value.
Thank you, I appreciate it 
So now all dependancies build correctly, and the gdb build is started but fails somewhere along the way with the message below. Would you have a pointer for this as well maybe?
g++ -x c++ -g -O2 -I. -I. -I./common -I./config -DLOCALEDIR=""/packages/gdb-8.1-2/.self/data/locale"" -DHAVE_CONFIG_H -I./…/include/opcode -I./…/opcodes/… -I./…/readline/… -I…/bfd -I./…/bfd -I./…/include -I…/libdecnumber -I./…/libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/packages/python-2.7.18-1/.self/develop/headers/python2.7 -I/packages/python-2.7.18-1/.self/develop/headers/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -c -o arch/i386.o -MT arch/i386.o -MMD -MP -MF arch/.deps/i386.Tpo arch/i386.c
In file included from /boot/system/develop/headers/posix/sys/types.h:127,
from build-gnulib/import/sys/types.h:28,
from build-gnulib/import/stdint.h:96,
from arch/i386.h:19,
from arch/i386.c:18:
build-gnulib/import/string.h:532:1: error: expected ‘,’ or ‘…’ before ‘__dest’
_GL_FUNCDECL_SYS (mempcpy, void *,
^~~~~~~~~~~~~~~~
build-gnulib/import/string.h:535:19: error: nonnull argument with out-of-range operand number (argument 2, operand 2)
_GL_ARG_NONNULL ((1, 2)));
^~~~~~~~~~~~~~~
Makefile:1624: recipe for target ‘arch/i386.o’ failed
make[2]: *** [arch/i386.o] Error 1
make[2]: *** Waiting for unfinished jobs…
make[2]: Leaving directory ‘/sources/gdb-8.1/gdb’
Makefile:8823: recipe for target ‘all-gdb’ failed
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory ‘/sources/gdb-8.1’
Makefile:848: recipe for target ‘all’ failed
make: *** [all] Error 2
Warning: Command ‘[‘bash’, ‘-c’, ‘. /wrapper-script’]’ returned non-zero exit status 2.
Error: Build has failed - stopping.
EDIT:
So it seems the keyword ‘restrict’ is not known, some mangling maybe?
Are you on a 32bit install? If so, you need to specify that you want the “secondary architecture” version of the recipe, to use gcc8 (newer version of gdb won’t build with gcc2)
So, instead of “haikuporter gcc” you need to use “haikuporter gcc_x86”, and in this case it will do a build with gcc8. For this to work, you need to configure the secondary_target_architecture as “x86” in haikuports.conf: HaikuPorter HaikuPortsConf · haikuports/haikuports Wiki · GitHub
(The syntax is a bit obscure here; the idea is that there are two architectures called x86_gcc2 and just x86, and currently the default is to use the x86_gcc2 architecture)
2 Likes
I am actually on a 64bit install trying to do a 64bit build…