I installed latest adtools, set GCC assign and PATH according to readme but I'm receiving a lot of errors about undefined reference to __gthread* even on simplest source, like:
/Work/adtools/bin/../lib/gcc/ppc-amigaos/8.1.0/clib2/libgcc_eh.a(unwind-sjlj.o): In function `_Unwind_SjLj_GetContext':
/var/lib/jenkins/workspace/native-gcc-8/gcc/repo/libgcc/unwind-sjlj.c:147: undefined reference to `__gthread_getspecific'
/var/lib/jenkins/workspace/native-gcc-8/gcc/repo/libgcc/unwind-sjlj.c:147: undefined reference to `__gthread_getspecific'
/var/lib/jenkins/workspace/native-gcc-8/gcc/repo/libgcc/unwind-sjlj.c:147: undefined reference to `__gthread_getspecific'
/var/lib/jenkins/workspace/native-gcc-8/gcc/repo/libgcc/unwind-sjlj.c:147: undefined reference to `__gthread_getspecific'
/var/lib/jenkins/workspace/native-gcc-8/gcc/repo/libgcc/unwind-sjlj.c:147: undefined reference to `__gthread_getspecific'
/SDK/clib2/lib/libc.a(stdlib_program_name.o): In function `stdlib_program_name_init_ctor':
stdlib_program_name.c:(.text+0xe4): undefined reference to `GetProgramName'
am I missing something? some flag maybe? I'm unable to find any clues regarding this
Latest gcc have support of native amigaos threads, which is didn't turn "on" by default (as was in testing, probabaly Sebastian will do it later), but then you also can't link without them. So for now, if you want to compile anything which use c++ / threads and stuff, you need to do it by adding : "-athread=native" option, as well as adding at end "-lpthread".
Unless the software in question actually uses c++ threads you might be better off using -athread=single.
Also clib2 is not thread safe so if the code does use some form of multithreading you will want to use newlib or clib2-ts which is the thread safe variant of clib2.
It helped with my code, it now works as it should.
I will try to recompile the DevilutionX code, but it uses cmake which is hardcoded to use newlib while adtools should be used by clib2, I wonder if that might be an issue or not. No idea if cmake is compatible with clib as well
@NoCache Adtools not forced to use clib2, i use it everywhere with newlib :) If you need specially clib2 by some reassons, you always can add flag like "-mcrt=clib2" when compile objects.
Also if you use CMAKE, you should be on crosscompiler, with native one you will have all sort of weird issues.
For cmake you can add that clib2 flag when you build makefiles, or when all builds, find out necessary makefile, and manually add that flag to cflags.
I have makefiles already generated by cmake with SDK's version of GCC so I will probably try to just modift it for adtools and see how it goes and I will stick with newlib then :)
Keep in mind, if you want to modify makefile to use clib2, then pretty possible you may have some problems when you will build your objects , as some of functionality which present in newlib, do not present in clib2.
I think I will stay with newlib,it was build previously succesfully and when You wrote adtools can be safely used with newlib, I don't see any reason to move to clib then :)
I got those gthread errors while compiling DevilutionX, so I added -athread=native -lpthreads flags and now I got this:
[ 2%] Linking CXX executable devilution
ld: cannot find gthr-amigaos-native.o: No such file or directory
ld: Warning: alignment 4 of symbol `channel' in CMakeFiles/devilution.dir/Stub/sound.cpp.obj is smaller than 8 in /SDK/local/newlib/lib/libSDL2_mixer.a(playmidi.o)
gmake[2]: *** [devilution] Error 1
gmake[1]: *** [CMakeFiles/devilution.dir/all] Error 2
gmake: *** [all] Error 2
the library is present in GCC:lib/gcc/ppc-amigaos/8.1.0/ I also tried it to link it to gcc:lib and /SObjs, include the folder with -L flag but now use...
Actually I got error about missing lgcc library, I linked it into GCC:lib folder and now it needs gthr-amigaos-native.o which is unable to find.
@NoCache Never seen that error, but seems indeed some mess with libs you tried to link with.
Usually, the rulez i follow all the time when compiling/port something big are:
1). Never use sobjes. That mean no "-use-dynld" flags or kind, no "dynamic". Preferable always set "-static" at the begining of linking line.
2). I never trust the how configure or cmake create for me final linking line. It most of time have wrong order, or put not what i need to. So, i always had to adapt makefiles (be it makefiles done via ./configure, or via cmake).
For example, that the final linking line i have for one game (newlib / latest adtools , via crosscompiler on cygwin):
If you didn't mess with the GCC installation (which is possible, like you maybe copy some clib2 library to newlib directory, or re-copy includes somewhere), then all should be fine.
In end, to be sure what your final linking line looks like, just do "cmake VERBOSE=1" , so you will see real linking line, and what flags it have and what libs and in which order it tried to put.
ps. why its gcc 8.1.0 ? Should be 8.2.0. Are you on crosscompiler or taking some auto-build native version from bintray.com ?
Indeed, I probably messed up the libraries while experimenting, I will rather reinstall it. I'm in AmigaOS, using abc-shell, cmake, sdk and adtools it looked as best option to me... Downloaded latest adtools package available which gives me version 8.1.0, but I will double check that I don't have crosscompile environment set up but is seems to be better option as I can see thanks for the linking line :)
@NoCache Crosscompiler vs native build it's like sky and earth. With crosscompiler you never-ever have any issues with any of that things like cmake, autoconf, automake, configure, shells, bisons, yawns, perls, seds, pythons, and all sort of things which can be used by ppls when they do things for unixes. And as bonus, its much faster compiling.
I have 2 versions setup : MSYS2 one, and CYGWIN one, CYGWIN one is more easy to use, where everything always works. You of course will need to know how to spawn right arguments to cmakes/configures/etc, so they will take not the host gcc, but crosscompiler gcc, but that all more or less easy and will save lot of your time.
As for 8.1.0, it seems something wrong with those automatic builds from bintray.com.
@NoCache That guide for MSYS, but if you want to use CMAKE and all that stuff with no problems, then build it for CYGWIN instead (you will have no pain with cmake and win32 pathes like double backslaches and all that C:\ and co).
As for debugging, to say it truth: there is no usable for real debuggers on amigaos4 (gdb buggy, db101 unfinished). So the only debugging techniq you can use are good old prinfs + serial cable . And of course GR with crashlogs (to have good information in crashlogs, you need to build your app with -gstabs). There is some article i wrote some time ago which will help to sort things out about debugging and stuff:
Finally I got the crosscompiler working after two days of installations, reinstallations debugging etc...
Now maybe little stupid questions, but... Include files the project I'm trying to compile needs, like SDL,GL etc, should I install them with cygwin installator or download the libs from os4depot and put them to crosscompiler directory somewhere? Also Cmake on amiga has it's own platform specification file.. should I use this one, default one that it is using by default or write new one? Are there any simple tutorials for this maybe? It would be handy for beginners like me to see the correct process steps.
@NoCache Cygwin's installer need it only for installing necessary host's tools (all those cmakes, autotools, autoconfs, etc). For all specific amiga things like libraries and co you of course need to use ones from os4depot, as those ones which you install for cygwin are for win32.
If you install everything well, you should now have /usr/local/amiga/ppc-amigaos/SDK/ directory, in which all the SDK and gcc files placed. When you will download any developer library from os4depot, you will need to install it here. I prefer to do everything manually, just via total commander going in one panel to the content of archive, and in other one going to c:cygwin/usr/local/amiga/ppc-amigaos/SDK/ or so.
Every developer archive from os4depot (almost all of them), have structure where root of content are SDK directory, so you need to copy libs and headers right as they placed in archive. Newlib ones to newlib, clib2 ones to clib2, etc,etc,without messing it around in all the places.
For first you may try to download let's say SDL2 developer archive, install it, write simple test case programm, compile it via "ppc-amigaos-gcc -static -athread=native test.c -o test -lSDL2 -lpthread" and check if all works fine and runs on aos4.
Once you done with it (which will mean you got the idea of how all structured, etc), you can go deeper by porting things.
There is 2 ways mostly when you port stuff: old one via ./configure way, and new one via CMAKE.
When you use ./configure, then you add 3 specific things at begining always:
Of course that mean without specific options to project itself, those ones are necessary as for ./configure things above : to show to cmake that we on crosscompiler, which gcc binaries will be used and from where. That line will generate necessary makefiles (and you have no needs to any platform specific files, all will be generated as need it). And then just "make" and all things will be inside of "build" directory (where will be and makefiles and stuff, which you will need to alter to have normall final linking line).
As for articles for beginners , there are some 10 years old guide from SpotUP, which quite dated, but still can give some clue as well.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
