How to build AmigaOS4 cross-compiler (Binutils 2.23.2 & GCC 8.3.0) on CYGWIN

@Raziel
Quote:

Dunno, again looks something like with perl ?:)

That how i build foobillard:

Quote:

Quote:

Those which used only to generate something which is not fits into the amigaos4 binary sure can be used on cross. But glib its a library which fits into binary so can't. autotools can.

@kas1e

well, perl should be installed correctly now.

This is btw the exact same error i'm getting when trying to compile it natively, so probably some dependency missing.

So everything which uses glib will not work?
Too bad, no fancy addon for scummvm then...

Need to find something different, right now it doesn't really seem to gain much for me, cross compiling wise.

But, thanks a lot for the guide, very easy to set up and will hopfully help some people to port or develop.


edit:
gettext-devel was missing, the error is gone, but now even more pop up.
It wants libtool and some other libraries...we are missing too many packages...

@Raziel
Quote:

By GLIB you mean C Library? That one which one is a different implementation of C libs, like our Newlib and Clib2? If so, how can you expect that x86 code will works on amigaos4 ?:) Sure not. And cross-compiler's pluses is not to make magic binaries which will have inside x86 code and works :) The reasons to have cross-compilers are:

1). Speed of compilation
2). All auto-tools, languages, interpretations and stuff can be used
3). Easy to work with a big amount of data because of x86 hardware


Quote:

Not sure what you mean, but if you on cross-compiler, you miss there nothing, just install what needs it. Libtool is the same "autogenerate" thing, which ok to be on cross-compiler.

You will step by step deal with all missing dependencies, and after a while will have them all, and every new project will ask almost nothing.

It's only about GLIBC I say, which is binary code which will be inside of binaries, of course, can't be used. I mean, you can't expect that you do -lglib on linking stage and amigaos4 binary will link inside x86 glib, and binary will works. Of course not. But any tools used for generating anything which will be not in the binary, all fine.

With cross-compiler, you have ALL auto tools working on the latest versions. But you still need to do some work, of course !:)

"libtool" is a tool to generate some crap: can be used. But if you need some real library, it should be ported to works on amigaos4 of course.

I mean "we missing too many packages" what that it mean ?:) On cross compiler, for cross compiler work, you miss nothing absolutely. Everything here of the latest version. If you miss something on amigaos4, it need to be done or ported, that what we all do.

@kas1e

Understood.

Sorry if i annoy with noob questions.
Just trying to find similarities between native and cross compile to be able to incorporate the two one day or another.
I still plan to do most natively (even if it means slow[er] compiling) to be able to report bugs and hope for updates

I didn't expect a cross-recompile to hit so many missing dependencies.

glib 2.0 dependent stuff is a nogo then, understood.

How do i know if a dependancy will be impossible?
you explained why glibc won't work, but what about other stuff.
Just an example here, would anything work that needs libtool or gettext?

Heck, maybe it's better if i stay away from cc and limit myself to the stuff that is available natively...

Question:

if i cc a "library" (static or shared) for amigaos, and it is installed (make install) to usr/local/lib, will it still be the library i could use in a native compile or does it have to be installed to sdk/local/lib?
Or doesn't that matter?
(I'm talking about the library that is installed on the cygwin side, i know that i have to move it to my native sdk if i want to use it on amigaos4)

@Raziel
Quote:

Sorry, I don't understand what you mean there. Cross-compiler has exactly the same missing dependencies as amigaos4 if you refer to the libraries which will be linked to the binary. There is no difference between cross-compiler or native build. All the same.

Cross-compiler only gives you speed, and those things which help you to generate makefiles, parse/generate configure scripts, etc, etc. I.e. preparation work which you can't on amigaos4 because of missing tools need it for that, because of dependencies on "sh", because of bugs in the porting process. With a cross-compiler, you have no problems with that. But only that. Maybe also things for those who didn't have amigaos4 machine to compile native, also it helps. But nothing else.

All the missing dependencies which come inside of binary, are absolutely the same of course. Crosscompiler didn't give you any new amigaos4 libraries. It only helps you with speed and auto-generation things.

It's like when you can't compile something because it wants new Python, or new Perl, or new CMake, or whatever. And you use cross-compiler ones. I.e. helper tools. But everything which comes _inside_ of the binary, missing exactly the same you compile it on amigaos4.

Cross compiler there only gives you the ability to run GCC compiled for x86, which builds amigaos4 binaries. But that all. And that is good too if you do port work. Every big project today have pretty heavy build processes, so to just compile them you need to do preparation work. Sure you can do all native, by losing lot of time or do it in an hour-two on cross-compiler.



I surprised that you think that it can give you anything else. I mean, if it was like this, why then we didn't port everything from the whole world already. In some way everything is a library: QT, XWindow, GLIB, DirectX, etc, etc: all of this platform-dependent, and of course need to be ported/rewritten. You can't just expect from cross-compiler that it all somehow ports only because you install cross-compiler :)

Quote:

You need to check what libtool is, and what is gettext. If I remember right, libtool is for _generating_ something, not a thing that comes inside of binary. So it's ok. Gettext from another hand, its some library used in the source code and linked to the binary then, which of course you need to have amigaos4 native, and link with it does not matter where, be it native, or cross compiler.

Quote:

Everything which you have amigaos4 native, shouldn't be installed anywhere in cross-compiler but only to the SDK directory and it will be used only from there.

All libraries which are x86, and installed on Cygwin, will work only for x86.

In other words, the cross-compiler only gives speed and Autotools. If it not what you need, forget it then :) You probably expect just too much from :)

If you didn't plan to work on something else, but just on scummvm, and the speed of compilation already fine for you, and you have no problems with the building process on amigaos4 already, then cross-compiler also probably not of big needs for you.

@kas1e

I did plan to "try and port" the speech dispatcher program (speechd on github) to amigaos4.
With that (and the already on amigaos4 available "FLite") it would have been possible to integrate it into ScummVM and make designated and supported games "speak" like it was in the days of the "say" command.

Remember Maupiti Island and Mortville Manor?
Just like that...but since speechd needs glib that will be out of the question now.

I'll keep the cygwin install, maybe i'm stumbling over something else that cannot be done natively (due to outdated native sdk parts), but i'm not educated in the field of porting and coding enough to be able to achieve anything else than more noob questions, so i'll drop it for now.

Still, have my hearty thanks for all the help and be assured that i will post more noob questions in the future.

Need to get back to bother capehill...he probably feels lonely already

$ ./configure --build=x86_64 --host=ppc-amigaos --target=ppc-amigaos
-bash: ./configure: No such file or directory


Can't find configure anywhere. Where should the config be located?

It's not necessary that the thing you want to compile will have ./configure. A project may use CMake, of Scons, or whatever else. Or Makefiles already have done, and no configure present. Or, configure script need to be generated by Autotools. In other words that all depends on the thing, you want to compile. Usually, if "configure" is used, it very well may be in the root directory, but sometimes it can be anywhere else, it all depends. Usually, you should have some readme about how to compile.

@kas1e

Thanks. There’s already a Makefile. The source code is for x64/Linux (and Windows) and requires at least g++ 4.7 (C++11), I have 8.3 installed.

@arfcarl
In that case, you need to copy your Makefile to something like Makefile.amigaos4, then inside of new makefile find out all instances of "gcc", "g++" "ar" and replace it on "ppc-amigaos-gcc", "ppc-amigaos-g++" and "ppc-amigaos-ar".

If in that makefile no such strings, then you yourself add at top something like:

Quote:

And you may need other adjustements (at least for linking line 100%), but that again depends.

Simple test:

#include <string>

int main()
{
std::to_string(0);
return 0;
}


$ ppc-amigaos-g++ to_string-test.cpp -o to_string-test
to_string-test.cpp: In function 'int main()':
to_string-test.cpp:5:10: error: 'to_string' is not a member of 'std'
std::to_string(0);
^~~~~~~~~


I will look into the hints given here:
https://stackoverflow.com/questions/12 ... ember-of-std-says-g-mingw



Edit:

Solved with these two steps:
1. https://github.com/sba1/adtools/issues/58#issuecomment-455441830
2. Added "-athread=native"


Now it compiles:
$ ppc-amigaos-g++ -athread=native to_string-test.cpp -o to_string-test

$ ppc-amigaos-readelf -h to_string-test
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: PowerPC
Version: 0x1
Entry point address: 0x10019bc
Start of program headers: 52 (bytes into file)
Start of section headers: 1132740 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 40 (bytes)
Number of section headers: 42
Section header string table index: 39

Next problem:


#include <stdio.h>
#include <stdlib.h>

int main()
{
printf("PATH = %s\n", getenv("PATH"));
unsetenv("PATH");
return 0;
}


$ ppc-amigaos-g++ -athread=native unsetenv-test.cpp -o unsetenv-test
unsetenv-test.cpp: In function 'int main()':
unsetenv-test.cpp:7:3: error: 'unsetenv' was not declared in this scope
unsetenv("PATH");
^~~~~~~~
unsetenv-test.cpp:7:3: note: suggested alternative: 'setenv'
unsetenv("PATH");
^~~~~~~~
setenv


Why is setenv okay but not unsetenv?

We dont have unsetenv(), as for us its setenv with 0. In other words, safely comnent it out, or replace on setenv var to 0.I always comment this out.

@kas1e

Thanks. That should be okay I suppose.


Next question:

Linux has both CMSG_SPACE and CMSG_DATA as seen here: http://man7.org/linux/man-pages/man3/cmsg.3.html

But for Amiga it seems, according to socket.h, that only CMSG_DATA is supported?


c++ compiler suggests CMSG_DATA instead of CMSG_SPACE, but it can't be that simple I presume. The result is:

error: conversion from 'uint8_t*' {aka 'unsigned char*'} to 'unsigned int' in a converted constant expression
char cmsgbuf[CMSG_DATA(sizeof(int))];

Now on to see how much change of code this means.

@arfcarl
There can't help, I do not remember much about it, as I rarely use network and stuff, but most of time it all compiles without changes, or with commenting out ipv6 parts.

@kas1e

I'll leave that for later.


Fork problem:

#include <unistd.h>

int main( int argc, char* argv[])
{
pid_t procID;

procID = fork();
return procID;
}


$ ppc-amigaos-g++ -athread=native fork.cpp -o fork
fork.cpp: In function 'int main(int, char**)':
fork.cpp:7:14: error: 'fork' was not declared in this scope
procID = fork();


The only unistd.h file I can find fork in is in \usr\local\amiga\ppc-amigaos\SDK\newlib\include\sys\unistd.h

It's like the compiler is not using this SDK/newlib include file? How fix that in the proper way? Or is the code "too unix" to be usable?

@arfcarl
A fork is bad. The only thing which is never properly can be "cross-compiled". You always need to check what exactly it does. If it used just to spawn a new process, you can use something like "systemtags()" (new version of execute()). But I not in "fork" things much too, and can't say how normally overwrite it. Usually, when it used heavy in projects a simple give up.

@kas1e

Yes, this is a “loop.cpp” that the whole program is depending on. It makes one fork, when that is finished it moves on to the next fork and so on.

I've ran into an issue. When I try to run the
Quote:
command, I get this error:

Quote:
Did this happen to anyone else? Maybe they deleted/moved some branch from the official GCC repo?

@BSzili
Seeing commit logs of adtools, seems nothing was changed. Maybe you just come to some wrong directory at some point, or forget to type something.. "Gild" itself wasn't updated too.