sba1 / adtools Goto Github PK

GCC 4.0.4 have been the last version supporting baserel compilation for AmigaOS4 target. After that it had been removed from our patches for some unknown reasons.

Since there are projects like https://github.com/jens-maus/amissl strongly relying on baserel compilation it would be really great if our baserel patches could be readded to our patchset. Here the Amissl project could serve as a perfect test case due to its high conplexity and strong use of global variables in the library interface...

Following example works when linked statically, like "g++ sstream.cpp". If linked like "g++ sstream.cpp -use-dynld" caused binary to crash when started, due to an unresolved symbol.

Tested with https://dl.bintray.com/sba1/adtools-native/:adtools-os4-20170309-402.lha

#include <sstream>

int main(void)
{
    std::stringstream ss;
    ss << "hello";

    return 0;
}

Currently, GCC is built with --enable-languages=c,c++. Can you please change this to --enable-languages=c,c++,objc,obj-c++? The overhead is minimal, but it allows using ObjC and ObjC++ on AmigaOS 4.

I'm trying to compile gcc5 with cross compiling option enabled and i'm using the usual:

make -C native-build gcc-cros

to compile the gcc but i'm getting this error on BFD:

*** BFD does not support target powerpc-unknown-amigaos.
*** Look in bfd/config.bfd for supported targets.

What is changed in the meanwhile? i've already compiled it on another machine without any problem.

Daily packages with the built cross compiler normally found at http://dl.bintray.com/sba1/adtools-deb have been missing for some time now.

Please fix, it was really nice to have them.

The builds over at: https://dl.bintray.com/sba1/adtools-native/
are broken. Critical binaries such as gcc, g++, etc. have weird names with pipe symbols ("|") in them. It looks like they're supposed to be symbolic links, but somehow the symbolic link ended up being "|".

Maybe it's an issue with the daily build machine, but it could just as easily be a bug in one of the build scripts.

NOTE: I just checked the latest adtools-8 (adtools-os4-8-20180625-682.lha), and it has this problem.

Please try this:

cd ram:
makedir test
echo blah > test/blah
rm -rf test

For me, the "rm" command doesn't return.

I'm getting the above error whilst trying to run the makefile for libiconv with gcc 5.3.0

Apparently the fix is to add --enable-plugins to the configure line when building binutils.

I've tried this (for the cross compiler) and it works. Please can this be added to the makefile in the repo.

index bea129b..4ff5c32 100644
--- a/binutils-build/Makefile
+++ b/binutils-build/Makefile
@@ -18,6 +18,7 @@ all: cross
 cross:
    mkdir -p $(CROSS_BUILD_DIR)
    cd $(CROSS_BUILD_DIR); CFLAGS="-Wno-switch -Wno-unused" $(REAL_SRC_DIR)/configure \
+                                   --enable-plugins \
                                    --target=ppc-amigaos \
                                    --prefix=$(PREFIX)
    make -C $(CROSS_BUILD_DIR)

I assume it is needed for the native binutils too, but I've not used that at all so I don't know.

Cross-Compilation succeeded only once I hand-patched binutils sources,

Request change to a known stable 2.23.2 versuon archive, possibly update to recent stable to replace
Existing sources.

I recall having to hand-patch (using latest stable as reference) several files in relation to a -1 being shifted,
Usually setting a "-(1 << CONSTANT_VALUE)" replacing the "( -1 << PPC_OPSHIFT_INV)" usage.

The root-native second pass building an AOS4 compiler itself failed as the clib2 and newlib headers are lacking a stdlib.h when building the c-lang.c file within the repo/gcc/c/ folder.

I am successfully attempting to test build with failure to link _gcov... Symbols with the root-cross toolchain. (see separate issue for this)

As the title says... I'm trying to use https://github.com/nlohmann/json and compilation fails with the latest Clib2 adtools-os4-clib2-20180708-690.lha and G++ (native) and compilation fails because "strtof is not a member of std".

Thanks for any help.

When i use -use-dynld flag to link a shared object i get a warning that libc.so is not found. And indeed i didn't see it into newlib folder. How can i compile shared objects? I have only the static one

I've found that when running a ./configure script under OS4.1 it keeps getting confused by Unix paths and this time it keeps trying to write to a config.h: volume. I've updated my make, clib and abc-shell just now. No change. Running in abc-shell doesnt seem to help much. For some reason when I attempt to assign the volume it never works and it keeps asking for the same volume again. OS4 has had this assign issue for years. Here's an excerp from the log:

creating ./config.status
creating Makefile
creating config.h:config.in
bin:cat: ./config.h: No such file or directory
bin:rm: cannot lstat `config.h:config.in': Device not configured
bin:mv: cannot stat `config.h:config.in': Device not configured

I get these undefined references linking to libatomic:

> ppc-amigaos-g++ -c -mlongcall -fpermissive -std=gnu++11 -fvisibility=hidden -fvisibility-inlines-hidden -O2 -Wall -W  -I/Users/alfkil/CODE/qtbase-amigaos4/config.tests/common/atomic64 -I. -I/Users/alfkil/CODE/qtbase-amigaos4/mkspecs/amigaos-g++ -o atomic64.o /Users/alfkil/CODE/qtbase-amigaos4/config.tests/common/atomic64/atomic64.cpp
> ppc-amigaos-g++ -use-dynld -Wl,--export-dynamic -Wl,-rpath-link,/SDK/newlib/lib -Wl,-rpath-link,/SDK/local/newlib/lib -o atomic64 atomic64.o   -L/SDK/newlib/lib -L/SDK/local/newlib/lib -lpthread -lunix -latomic 
> /Users/alfkil/CODE/adtools/native-build/root-cross/lib/gcc/ppc-amigaos/5.4.0/../../../../ppc-amigaos/lib/libatomic.so: undefined reference to `libat_unlock_n'
> /Users/alfkil/CODE/adtools/native-build/root-cross/lib/gcc/ppc-amigaos/5.4.0/../../../../ppc-amigaos/lib/libatomic.so: undefined reference to `libat_lock_n'

#include <atomic>
#include <cstdint>

void test(volatile std::atomic<std::int64_t> &a)
{
    std::int64_t v = a.load(std::memory_order_acquire);
    while (!a.compare_exchange_strong(v, v + 1,
                                      std::memory_order_acq_rel,
                                      std::memory_order_acquire)) {
        v = a.exchange(v - 1);
    }

    a.store(v + 1, std::memory_order_release);
}

int main(int, char **)
{
    void *ptr = (void*)0xffffffc0; // any random pointer
    test(*reinterpret_cast<std::atomic<std::int64_t> *>(ptr));
    return 0;
}

With the release of the new installer, the relative version bump induced a reinstall of the SDK (that was pinned to the first SDK). The installer script fails (thus preventing any other package change) with this error:

mv: inter-device move failed: `/tmp/adtools-sdk.iu3aYULGiHV/clib2' to `/usr//ppc-amigaos/SDK/clib2'; unable to remove target: Is a directory
mv: inter-device move failed: `/tmp/adtools-sdk.iu3aYULGiHV/newlib' to `/usr//ppc-amigaos/SDK/newlib'; unable to remove target: Is a directory

This is due to: (from the script)
mv ${EXTRACTDIR}/clib2* ${EXTRACTDIR}/newlib* ${CROSS_ROOT}/ppc-amigaos/SDK

So we could run the script with --uninstall as a prerequisite, however this doesn't ensure the corresponding two directories will be removed, if there are any "user added" files in those two.

The other way would be yet more bash shenanigans, checking if the directories exists.

Hi.

I've tried compiling natively a small C++ example and it fails with many missing references to calls such as __gthread_getspecific , __gthread_setspecific and __gthread_active_p .
The references are from unwind_sjlj and others in the C++ library (include/ext/atomicity.h) .

If I forcefully supply the gthr_amigaos_native.o on the command line, then link is successfull and the program run.

AmigaOS4.1 FinalEdition Update 1
rm (GNU coreutils) 8.27

e.g. directory has a subdirectory which has files in it (files flagged as deletable and read/writable)

rm -f -r directory/subdirectory
rm: cannot remove 'directory/subdirectory': Directory not empty

Doesn't matter if it's started from within a makefile, an sh shell or an Amiga shell.

Maybe i'm doing something wrong, but shouldn't the -r recursive flag take care of all the files inside that subdirectory?

Breaks nearly all "gmake -clean" commands of porting projects.

When I try to compile C++ programs with GCC 6.1.0 I often get an error like:

/usr/local/amiga/adtools-gcc-6/ppc-amigaos/include/c++/6.1.0/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>

The problem is, I think, caused by the fact that /SDK/newlib/include is too early in the include search list (before the compiler's c++ includes) and the fact that was changed to using include_next for including <stdlib.h>.

#include "..." search starts here:
#include <...> search starts here:
/usr/local/amiga/adtools-gcc-6/ppc-amigaos/SDK/newlib/include
/usr/local/amiga/adtools-gcc-6/ppc-amigaos/SDK/local/newlib/include
/usr/local/amiga/adtools-gcc-6/ppc-amigaos/SDK/include/include_h
/usr/local/amiga/adtools-gcc-6/ppc-amigaos/SDK/include/netinclude
/usr/local/amiga/adtools-gcc-6/ppc-amigaos/SDK/local/common/include
/usr/local/amiga/adtools-gcc-6/lib/gcc/ppc-amigaos/6.1.0/../../../../ppc-amigaos/include/c++/6.1.0
/usr/local/amiga/adtools-gcc-6/lib/gcc/ppc-amigaos/6.1.0/../../../../ppc-amigaos/include/c++/6.1.0/ppc-amigaos
/usr/local/amiga/adtools-gcc-6/lib/gcc/ppc-amigaos/6.1.0/../../../../ppc-amigaos/include/c++/6.1.0/backward
/usr/local/amiga/adtools-gcc-6/lib/gcc/ppc-amigaos/6.1.0/include
/usr/local/amiga/adtools-gcc-6/lib/gcc/ppc-amigaos/6.1.0/include-fixed
/usr/local/amiga/adtools-gcc-6/lib/gcc/ppc-amigaos/6.1.0/../../../../ppc-amigaos/include
End of search list.

GCC 5 and earlier do not have this problem.

With the new 5.4 build I am having issue with a linker script not parsing the paths correctly. This example fragment of script issue.

INPUT( "Work:BMX/Build/mod/brl.mod/appstub.mod/appstub.release.amigaos4.ppc.a")`

At link time I get request to create assign for Work: which if I do and then look at assigns I see a new assign "Work Work: so there is something amiss with parsing of the quoted libs in my script. This works with original SDK fine.

Let me know what I might provide or where I might look to assist in correcting.

Regards
Doug

I've managed to run a build of the adtools project yet have no idea how to "install" it.

And would like this to remain within a single user home directory tree created for this task.

Tried to configure SDL2 after installation of the latest GCC 5.4.0.

Project page: https://sourceforge.net/projects/sdl2-amigaos4/

My paths:

14.Beta41:> path

RAM Disk:
Beta41:C
Beta41:S/Shell
Beta41:S/ARexx
Beta41:System/Python/Scripts
Beta41:Utilities
Beta41:Utilities/Commodities
Beta41:System
Beta41:Prefs
Code:SDK/C
Code:adtools-os4-20170623-404/bin
Code:SDK/local/C
Temp:Qt-4.7/bin
Code:cmake-3.7.1/bin
C:

14.Beta41:> echo $PATH
/SDK/c:/gcc/bin:/SDK/local/C:/code/cmake-3.7.1/bin

8.Code:svn/sdl2-amigaos4-code/trunk> sh configure --disable-altivec --prefix=/SDK/local/newlib
configure: WARNING: unrecognized options: --disable-0
configure: error: expected an absolute directory name for --prefix: 0

WORKAROUND: I inactivated gcc:bin/expr by renaming it, and then configuring passed and project was possible to build with make (even though there were lots of other errors during configuring).

Snoopy_Output_configure.txt

Hello. I installed the packages on Linux Mint 64. I also installed the extra libs needed to build it. Then tried to compile the test suite by a CD into the folder and a make. I got this back. Perhaps some extra dependencies need to be added in. Lintian gave a few errors on the packages also.

ppc-amigaos-g++ -v -c test-exceptions.cpp -o test-exceptions.o -ggdb Using built-in specs. COLLECT_GCC=ppc-amigaos-g++ Target: ppc-amigaos Configured with: patched/configure --target=ppc-amigaos --prefix=/usr --libexec=/usr/lib --with-bugurl=http://sf.net/p/adtools --with-pkgversion='adtools build ' --enable-languages=c,c++ --enable-haifa --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-tls --disable-nls Thread model: single gcc version 4.9.2 (adtools build ) COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'test-exceptions.o' '-ggdb' /usr/lib/gcc/ppc-amigaos/4.9.2/cc1plus -quiet -v -mcrt=newlib -isystem /usr/ppc-amigaos/SDK/newlib/include -isystem /usr/ppc-amigaos/SDK/local/newlib/include -isystem /usr/ppc-amigaos/SDK/include/include_h -isystem /usr/ppc-amigaos/SDK/include/netinclude -isystem /usr/ppc-amigaos/SDK/local/common/include test-exceptions.cpp -quiet -dumpbase test-exceptions.cpp -auxbase-strip test-exceptions.o -ggdb -version -o /tmp/ccSayMfQ.s /usr/lib/gcc/ppc-amigaos/4.9.2/cc1plus: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory makefile:7: recipe for target 'test-exceptions.o' failed make: *** [test-exceptions.o] Error 1

Testing new toys. A simple thread creation compiles, links and works. Std::async didn't:

#include <thread>
#include <future>

#include <cstdio>
#include <unistd.h>

int thread()
{
	printf("Hello from thread\n");
	return 0;
}

int main()
{
	//std::thread t(thread);
	auto fut = std::async(thread);

	printf("Hello from main\n");
	
	usleep(100000);	
	return 0;
}

g++ thread.cpp -athread=native

/Code/adtools-os4-8-20180519-611/bin/../lib/gcc/ppc-amigaos/8.1.0/../../../libstdc++.a(condition_variable.o): In function std::condition_variable::~condition_variable()': /var/lib/jenkins/workspace/native-gcc-8/gcc/repo/libstdc++-v3/src/c++11/condition_variable.cc:46: undefined reference to __gthread_cond_destroy'

In the GCC 5.3.0 distribution on aminet, there are several mistakes in the directory structure, preventing c++ apps from building.

Files in

adtools-os4-20151223-268/lib/gcc/

need to be copied to

adtools-os4-20151223-268/lib/gcc/ppc-amigaos/5.3.0/newlib/lib

--
and files in

adtools-os4-20151223-268/lib/gcc/ppc-amigaos/5.3.0/lib/#?

need to be copied to

adtools-os4-20151223-268/lib/gcc/ppc-amigaos/5.3.0/newlib/lib/

I'm well aware this would require a path that is assigned to ownership by the user actually performing the build operation.

"mkdir -p $(target_path)" as root followed by chown and chgrp execution.

Would this be possible as an optional script for anyone to use non-debian/redhat hosts as additnal distcc nodes with a native compiler built for the master amigaos machine for anyone who has multiple machines to make a build cluster?

I use native adtools-os4-20170623-404.

In the official SDK, I get many tools with the prefix "ppc-amigaos-":

7.RAM Disk:> list sdk:gcc/bin/ppc-amigaos-#?
Le répertoire « sdk:gcc/bin » le Samedi 25-Nov-17
ppc-amigaos-strip 1419884 ----rwed 06-Sep-15 05:49:37

strip
ppc-amigaos-strings 1085792 ----rwed 06-Sep-15 05:49:37
strings
ppc-amigaos-readelf 732728 ----rwed 06-Sep-15 05:49:37
readelf
ppc-amigaos-ranlib 1164584 ----rwed 06-Sep-15 05:49:37
ranlib
ppc-amigaos-objdump 1629068 ----rwed 06-Sep-15 05:49:37
objdump
ppc-amigaos-objcopy 1419880 ----rwed 06-Sep-15 05:49:37
objcopy
ppc-amigaos-nm 1094392 ----rwed 06-Sep-15 05:49:37
nm
ppc-amigaos-ld 1558628 ----rwed 06-Sep-15 05:49:37
ld
ppc-amigaos-gprof 1268812 ----rwed 06-Sep-15 05:49:37
gprof
ppc-amigaos-gcov 69148 ----rwed 06-Sep-15 05:49:37
gcov
ppc-amigaos-gccbug 15915 ----rwed 06-Sep-15 05:49:37
gccbug
ppc-amigaos-gcc 296536 ----rwed 06-Sep-15 05:49:37
gcc
ppc-amigaos-g++ 300432 ----rwed 06-Sep-15 05:49:37
c++
ppc-amigaos-cpp 298924 ----rwed 06-Sep-15 05:49:37
cpp
ppc-amigaos-c++filt 1082120 ----rwed 06-Sep-15 05:49:37
c++filt
ppc-amigaos-c++ 300432 ----rwed 06-Sep-15 05:49:37
c++
ppc-amigaos-as 1695360 ----rwed 06-Sep-15 05:49:37
as
ppc-amigaos-ar 1164580 ----rwed 06-Sep-15 05:49:37
ar
ppc-amigaos-addr2line 1084896 ----rwed 06-Sep-15 05:49:37
addr2line
ppc-amigaos-gcc-4.2.4 296640 ----rwed 06-Jan-09 14:24:46
20 fichiers - 17M octets - 600 blocs utilisés

In the tested adtools package, there are only few of these tools:

7.RAM Disk:> list work:Development/adtools-os4-20170623-404/bin/ppc-amigaos-#?
Le répertoire « work:Development/adtools-os4-20170623-404/bin » le Samedi 25-Nov-17
ppc-amigaos-gcc-ranlib 29752 ----rwed 23-Juin-17 04:39:15
ppc-amigaos-gcc-nm 29748 ----rwed 23-Juin-17 04:39:15
ppc-amigaos-gcc-ar 29776 ----rwed 23-Juin-17 04:39:15
ppc-amigaos-gcc-5.4.0 903868 ----rwed 23-Juin-17 04:39:15
ppc-amigaos-gcc 903868 ----rwed 23-Juin-17 04:39:15
ppc-amigaos-g++ 905752 ----rwed 23-Juin-17 04:39:15
ppc-amigaos-c++ 905752 ----rwed 23-Juin-17 04:39:15
7 fichiers - 3621K octets - 7256 blocs utilisés

And it seems than some are not correctly named: "ppc-amigaos-gcc-ar" instead of "ppc-amigaos-ar", that should be a link on "ar":

7.RAM Disk:> list work:Development/adtools-os4-20170623-404/bin/ar
Le répertoire « work:Development/adtools-os4-20170623-404/bin » le Samedi 25-Nov-17
ar 1232484 ----rwed 23-Juin-17 04:39:14

Also note that trying to execute, "adtools-os4-20170623-404/bin/ppc-amigaos-gcc-ar", that gives this error:

adtools-os4-20170623-404/bin/ppc-amigaos-gcc-ar: Cannot find plugin 'liblto_plugin.so'

Currently in c++config.h (I guess created by configure script) _GLIBCXX_USE_C99 is undefined.
This in turn prevents C++11 methods such as std::to_string() to work (they're undefined too), so to do such string manipulation you either have to use the c-library or string streams.

Thanks.

This would enable a more complete toolchain,

Again stable tarball is preferred, would this be possible?

Please find a way to build a cross for debian/amd64.
Building and shipping a working GCC 8 requires a fixed Clib2 but that in turn requires that Clib2 files from the SDK to be overwritten.

I get ISI exception when using libSDL built with GCC5. When application is started, and library constructor called, code jumps somewhere.

Here is a smaller example which has the same issue:

#include <stdio.h>

void _INIT_thread_init(void) __attribute__((constructor));
void _EXIT_thread_term(void) __attribute__((destructor));


void plistInit(int *param)
{
    if(param)
    {
        *param = 123;
    }
}

void _INIT_thread_init(void)
{
    int i;
    plistInit(&i);

    printf("init\n");
}

void _EXIT_thread_term(void)
{
    printf("exit\n");
}

int main(void)
{
    printf("main\n");
    return 0;
}

It needs to be compiled like:

gcc test.c -fPIC -use-dynld

running a.out generates ISI.

It should be possible to add an attribute to varargs derivatives of RawDoFmt() such as IUtility->SNPrintf() that causes the compiler to verify that format specifiers match the given parameters. If not a warning should be brought up.

The gcc has this feature since quite a while for printf()-style functions but these for now assume 32 bit ints while RawDoFmt() defaults to 16 bit width. The new attribute should probably be a variation of the existing attribute.

The cp in the latest gcc5.4 native build archive does not behave correctly when passed absolute paths for the src files.

See following session:

10.Programing:Projects/MultiViewer/trunk> which cp
Programing:SDK/gcc/bin/cp
10.Programing:Projects/MultiViewer/trunk> cp ram:T/usb.log ram:
cp: cannot stat `ram:/usb.log': Invalid argument
10.Programing:Projects/MultiViewer/trunk> cp /ram/T/usb.log /ram
cp: cannot stat `/ram/T/usb.log': No such file or directory

compared with the following session useful the builds from the previous SDK

10.Programing:Projects/MultiViewer/trunk> SDK:local/C/cp ram:T/usb.log ram:
10.Programing:Projects/MultiViewer/trunk> SDK:local/C/cp /ram/T/usb.log ram:

both successful copies

I notice the cp and presumably other coreutils commands in the package are newlib based but the older working ons are clib2 based.

I don't think 'core utils' was ever properly ported to newlib and there is now a new clib2 build down by SSolie which should be gcc5 compatable

Script fails during deinstalling rpm with the script:

Running Transaction
Error in PREUN scriptlet in rpm package ppc-amigaos-sdk
find: kan ‘/usr//ppc-amigaos/bin’ niet verwijderen: Map is niet leeg
find: kan ‘/usr//ppc-amigaos/lib/ldscripts’ niet verwijderen: Map is niet leeg
find: kan ‘/usr//ppc-amigaos/lib’ niet verwijderen: Map is niet leeg
find: kan ‘/usr//ppc-amigaos’ niet verwijderen: Map is niet leeg
fout: %preun(ppc-amigaos-sdk-53.24-amixdev.1.2.1.noarch) scriptlet failed, exit status 1

This is %preun from .spec file for building the rpm:

%preun
%{_prefix}/sbin/update-adtools-sdk-nonfree --uninstall

Because of this fail yum/rpm is not removed from db.
Directories are not empty as I have ppc-amigaos-binutils installed.

cp ./icons/residualvm_drawer.info Games:ResidualVM.info
gcc:bin/cp: skipping file `./icons/residualvm_drawer.info', as it was replaced while being copied
gmake: *** [amigaosdist] Error 1

It doesn't matter if the destination file exists or not.

cp 5.2.1 from the gcc 5.3.0 package errors
cp5.2.1-9 from the latest SDK 53.29 works fine

See title.

I can't compile code with std::mutex. Should it be supported?

2.Code:test> which g++
Code:adtools-os4-20170623-404/bin/g++

2.Code:test> g++ -c -std=c++11 mutex.cpp
mutex.cpp: In function 'int main()':
mutex.cpp:5:2: error: 'mutex' is not a member of 'std'
std::mutex m;
^

#include <mutex>

int main(void)
{
	std::mutex m;

	return 0;
}

After reboot the same code compiled without crash. Anyway, here is the crash log in case there is something useful. I'm using the latest native release.

Crashlog_cc1plus_2017-04-29_19-20-38.txt

I've managed to build the native compiler, but it's not clear how to generate the archive to be copied to my AmigaOS 4 machine.

It would be useful if the makefile auto-generated the archive and/or the readme documented how to generate it.

Compiling ScummVM (and ResidualVM aswell, they share the same code base) project leads to an early error pointing to a missing vsprintf if i usie the projects switch --enable-c++.
(Dropping the switch makes the compiler run without problems)

I'll crosslink to the projects bugreport because i don't really know what is going wrong or what i could do to resolve this or further test:
https://sourceforge.net/p/scummvm/bugs/6988/

If you need specific testing, please let me know

If you compile an Amiga program from an Amiga shell 'rm' will not work with wildcards. The 'rm' in the current OS4 SDK works when used with wildcards (like *.o) from an Amiga shell or an 'sh' (abc-shell) shell. If you have a 'clean' target in a makefile that uses something like 'rm -r -f *.o' and are accustomed to it working with the SDK 'rm' from an Amiga shell, your sources are not actually being cleaned if you use the new coreutils.

I did a hex search of the SDK 'rm' and the new 'rm' and it appears that the SDK 'rm' might be compiled with clib2. Regardless, something is different about the newly compiled 'rm" that keeps wildcards from working with an Amiga shell. This problem might also affect other coreutils that accept wildcards.

I'm trying to compile a C++11 project with gcc 5.4.0 but it doesn't work. I'm getting the error mentioned above. Here is the complete error message:

In file included from /dh1/Programmieren/adtools-os4-20170218-372/include/c++/5.4.0/bits/move.h:57:0,
       from /dh1/Programmieren/adtools-os4-20170218-372/include/c++/5.4.0/bits/stl_pair.h:59,
       from /dh1/Programmieren/adtools-os4-20170218-372/include/c++/5.4.0/bits/stl_algobase.h:64,
       from /dh1/Programmieren/adtools-os4-20170218-372/include/c++/5.4.0/vector:60,
       from ./fpdfsdk/cba_annotiterator.h:10,
       from fpdfsdk/cba_annotiterator.cpp:7:
/dh1/Programmieren/adtools-os4-20170218-372/include/c++/5.4.0/type_traits: In instantiation of 'struct std::make_unsigned<wchar_t>':
./core/fxcrt/cfx_string_c_template.h:28:67:   required from 'class CFX_StringCTemplate<wchar_t>'
./core/fxcrt/cfx_string_c_template.h:235:23:   required from here
/dh1/Programmieren/adtools-os4-20170218-372/include/c++/5.4.0/type_traits:1757:62: error: invalid use of incomplete type 'class std::__make_unsigned_selector<wchar_t, false, false>'
     { typedef typename __make_unsigned_selector<_Tp>::__type type; };
                           ^
/dh1/Programmieren/adtools-os4-20170218-372/include/c++/5.4.0/type_traits:1721:11: note: declaration of 'class std::__make_unsigned_selector<wchar_t, false, false>'
     class __make_unsigned_selector;
      ^
In file included from ./core/fxcrt/fx_string.h:11:0,
       from ./core/fpdfdoc/cpdf_annot.h:15,
       from ./fpdfsdk/cba_annotiterator.h:12,
       from fpdfsdk/cba_annotiterator.cpp:7:
./core/fxcrt/cfx_widestring.h:258:6: error: 'wostream' in namespace 'std' does not name a type
 std::wostream& operator<<(std::wostream& os, const CFX_WideString& str);
      ^
./core/fxcrt/cfx_widestring.h:260:6: error: 'wostream' in namespace 'std' does not name a type
 std::wostream& operator<<(std::wostream& os, const CFX_WideStringC& str);
      ^
In file included from ./core/fxcrt/cfx_bytestring.h:16:0,
       from ./core/fxcrt/fx_string.h:10,
       from ./core/fpdfdoc/cpdf_annot.h:15,
       from ./fpdfsdk/cba_annotiterator.h:12,
       from fpdfsdk/cba_annotiterator.cpp:7:
./core/fxcrt/cfx_string_c_template.h: In instantiation of 'CFX_StringCTemplate<T>::CFX_StringCTemplate(const CharType*, FX_STRSIZE) [with T = wchar_t; CFX_StringCTemplate<T>::CharType = wchar_t; FX_STRSIZE = unsigned int]':
./core/fxcrt/cfx_widestring.h:69:48:   required from here
./core/fxcrt/cfx_string_c_template.h:41:72: error: using invalid field 'CFX_StringCTemplate<T>::m_Ptr'
       : m_Ptr(reinterpret_cast<const UnsignedType*>(ptr)), m_Length(len) {}
                           ^
./core/fxcrt/cfx_string_c_template.h: In instantiation of 'CFX_StringCTemplate<T>::CFX_StringCTemplate(const CFX_StringCTemplate<T>&) [with T = wchar_t]':
./core/fxcrt/cfx_widestring.h:69:48:   required from here
./core/fxcrt/cfx_string_c_template.h:59:11: error: using invalid field 'CFX_StringCTemplate<T>::m_Ptr'
     m_Ptr = src.m_Ptr;
      ^
./core/fxcrt/cfx_string_c_template.h:59:11: error: 'const class CFX_StringCTemplate<wchar_t>' has no member named 'm_Ptr'
./core/fxcrt/cfx_string_c_template.h: In instantiation of 'CFX_StringCTemplate<T>::CFX_StringCTemplate(const CharType*) [with T = wchar_t; CFX_StringCTemplate<T>::CharType = wchar_t]':
./core/fxcrt/cfx_widestring.h:205:35:   required from here
./core/fxcrt/cfx_string_c_template.h:38:42: error: using invalid field 'CFX_StringCTemplate<T>::m_Ptr'
    m_Length(ptr ? FXSYS_len(ptr) : 0) {}
                 ^
./core/fxcrt/cfx_string_c_template.h: In instantiation of 'CFX_StringCTemplate<T>::CFX_StringCTemplate(CFX_StringCTemplate<T>::CharType&) [with T = wchar_t; CFX_StringCTemplate<T>::CharType = wchar_t]':
./core/fxcrt/cfx_widestring.h:212:49:   required from here
./core/fxcrt/cfx_string_c_template.h:54:11: error: using invalid field 'CFX_StringCTemplate<T>::m_Ptr'
     m_Ptr = reinterpret_cast<const UnsignedType*>(&ch);

How can I fix this please? On all other systems (MorphOS, Linux, Mac OS, Windows, Android) the code compiles fine but with the OS4 gcc 5.4.0 I'm getting this error and I haven't got a clue how to fix it. Looks like a compiler issue to me.

I'm invoking gcc like this:

gcc -c -std=c++11 -o test.o test.cpp

Clib2 comes in many flavours. When using -athread option, it probably would make sense to switch to the thread-safe variant by default. Otherwise, program probably don't work as expected (this has to be tested).

Taken from an initial post to os4beta

Broadblues wrote :

I'm currently working on merging the src of my perl upstream with the help
of Jarkko Hietaniemi one of the perl devs.

We've fixed the Configure script for number of amigaos quirks but this one
is abit interesting.

Perl 5.22 adds the -fstack-protector flag to most compile and link lines, as
an addistionalsecuity measure I believe.

1. Does -fstack-protector have any use / function on AmigaOS ie has it been
   implmented?

2. when compileing dynamically I get a link error

   /ram>echo 'int main() { return 0; }' > x.c
   /ram>gcc -o x -fstack-protector x.c

worked

/ram>gcc -use-dynld -o x -fstack-protector x.c
/GCC/lib/gcc/ppc-amigaos/4.2.4/newlib/lib/libssp.so: undefined reference to
`syslog'

failed

perl is built using -use-dynld so fails to link.

is this a bug or an umimplmented feature?

sbauer then wrote:

If there is any thing special that is needed to support this feature, it
is probably not supported.

Can you disassemble the output of the statically linked executable?

Followup:

Can't see a way to attach so here it is inline

x:     file format elf32-amigaos

SYMBOL TABLE:
01000074 l    d  .text  00000000 .text
01001000 l    d  .rodata    00000000 .rodata
01010000 l    d  .ctors 00000000 .ctors
01010008 l    d  .dtors 00000000 .dtors
01010010 l    d  .sdata 00000000 .sdata
01010014 l    d  .sbss  00000000 .sbss
00000000 l    d  .comment   00000000 .comment
00000000 l    df *ABS*  00000000 x.c
01010030 g     O .sbss  00000004 __stdiowin
01010028 g     O .sbss  00000004 UtilityBase
01010010 g       .sdata 00000000 _DATA_BASE_
0101001c g     O .sbss  00000004 IExec
01010010 g     O .sdata 00000004 __newlib_minversion_ptr
0101002c g     O .sbss  00000004 IUtility
01010034 g     O .sbss  00000004 __unix_path_semantics
01010014 g     O .sbss  00000004 __reent_magic
01010018 g     O .sbss  00000004 DOSBase
01000074 g     F .text  000001e8 _start
01018010 g       .sdata 00000000 _SDA_BASE_
01010024 g     O .sbss  00000004 INewlib
01010014 g       *ABS*  00000000 __bss_start
0100025c g     F .text  00000024 main
00000001 g       *ABS*  00000000 __amigaos4__
01010014 g       *ABS*  00000000 _edata
01010040 g       *ABS*  00000000 _end
01001018  w    O .rodata    00000004 __newlib_minversion
01010014 g     O .sbss  00000004 SysBase
01010020 g     O .sbss  00000004 IDOS


Disassembly of section .text:

01000074 <_start>:
 1000074:   94 21 ff c0     stwu    r1,-64(r1)
 1000078:   7c 08 02 a6     mflr    r0
 100007c:   3d 20 01 01     lis     r9,257
 1000080:   90 01 00 44     stw     r0,68(r1)
 1000084:   bf 21 00 24     stmw    r25,36(r1)
 1000088:   7c 79 1b 78     mr      r25,r3
 100008c:   7d bb 6b 78     mr      r27,r13
 1000090:   90 a9 00 14     stw     r5,20(r9)
 1000094:   3d 20 01 02     lis     r9,258
 1000098:   7c bd 2b 78     mr      r29,r5
 100009c:   83 e5 02 78     lwz     r31,632(r5)
 10000a0:   39 a9 80 10     addi    r13,r9,-32752
 10000a4:   7c 9a 23 78     mr      r26,r4
 10000a8:   80 1f 00 3c     lwz     r0,60(r31)
 10000ac:   7f e3 fb 78     mr      r3,r31
 10000b0:   7c 09 03 a6     mtctr   r0
 10000b4:   4e 80 04 21     bctrl
 10000b8:   81 5d 02 9e     lwz     r10,670(r29)
 10000bc:   3d 20 01 01     lis     r9,257
 10000c0:   3d 60 01 01     lis     r11,257
 10000c4:   3c 80 01 00     lis     r4,256
 10000c8:   93 eb 00 1c     stw     r31,28(r11)
 10000cc:   7f e3 fb 78     mr      r3,r31
 10000d0:   80 0a 00 10     lwz     r0,16(r10)
 10000d4:   38 84 10 00     addi    r4,r4,4096
 10000d8:   38 a0 00 34     li      r5,52
 10000dc:   90 09 00 28     stw     r0,40(r9)
 10000e0:   3d 20 01 01     lis     r9,257
 10000e4:   80 1f 01 a8     lwz     r0,424(r31)
 10000e8:   91 49 00 2c     stw     r10,44(r9)
 10000ec:   7c 09 03 a6     mtctr   r0
 10000f0:   4e 80 04 21     bctrl
 10000f4:   7c 7c 1b 79     mr.     r28,r3
 10000f8:   40 82 00 4c     bne-    1000144 <_start+0xd0>
 10000fc:   80 1f 02 3c     lwz     r0,572(r31)
 1000100:   3c 80 00 03     lis     r4,3
 1000104:   7f e3 fb 78     mr      r3,r31
 1000108:   60 84 80 0e     ori     r4,r4,32782
 100010c:   3b a0 00 14     li      r29,20
 1000110:   7c 09 03 a6     mtctr   r0
 1000114:   4e 80 04 21     bctrl
 1000118:   7f e3 fb 78     mr      r3,r31
 100011c:   83 ff 00 40     lwz     r31,64(r31)
 1000120:   7f e9 03 a6     mtctr   r31
 1000124:   4e 80 04 21     bctrl
 1000128:   80 01 00 44     lwz     r0,68(r1)
 100012c:   7f a3 eb 78     mr      r3,r29
 1000130:   7f 6d db 78     mr      r13,r27
 1000134:   bb 21 00 24     lmw     r25,36(r1)
 1000138:   38 21 00 40     addi    r1,r1,64
 100013c:   7c 08 03 a6     mtlr    r0
 1000140:   4e 80 00 20     blr
 1000144:   80 1f 01 c0     lwz     r0,448(r31)
 1000148:   3c a0 01 00     lis     r5,256
 100014c:   7f e3 fb 78     mr      r3,r31
 1000150:   38 a5 10 10     addi    r5,r5,4112
 1000154:   7f 84 e3 78     mr      r4,r28
 1000158:   7c 09 03 a6     mtctr   r0
 100015c:   38 c0 00 01     li      r6,1
 1000160:   38 e0 00 00     li      r7,0
 1000164:   4e 80 04 21     bctrl
 1000168:   7c 7e 1b 79     mr.     r30,r3
 100016c:   41 82 00 d0     beq-    100023c <_start+0x1c8>
 1000170:   3d 20 01 01     lis     r9,257
 1000174:   38 00 00 01     li      r0,1
 1000178:   81 69 00 10     lwz     r11,16(r9)
 100017c:   3d 20 01 01     lis     r9,257
 1000180:   3d 40 01 01     lis     r10,257
 1000184:   39 29 00 00     addi    r9,r9,0
 1000188:   3d 00 01 01     lis     r8,257
 100018c:   80 6b 00 00     lwz     r3,0(r11)
 1000190:   3d 60 01 01     lis     r11,257
 1000194:   3c c0 01 01     lis     r6,257
 1000198:   39 6b 00 08     addi    r11,r11,8
 100019c:   90 01 00 08     stw     r0,8(r1)
 10001a0:   3c e0 01 01     lis     r7,257
 10001a4:   91 61 00 10     stw     r11,16(r1)
 10001a8:   3d 60 01 01     lis     r11,257
 10001ac:   7f 24 cb 78     mr      r4,r25
 10001b0:   91 21 00 0c     stw     r9,12(r1)
 10001b4:   7f 45 d3 78     mr      r5,r26
 10001b8:   38 c6 00 18     addi    r6,r6,24
 10001bc:   93 c8 00 24     stw     r30,36(r8)
 10001c0:   3d 00 01 00     lis     r8,256
 10001c4:   38 e7 00 20     addi    r7,r7,32
 10001c8:   39 08 02 5c     addi    r8,r8,604
 10001cc:   80 1e 00 50     lwz     r0,80(r30)
 10001d0:   81 2a 00 30     lwz     r9,48(r10)
 10001d4:   81 4b 00 34     lwz     r10,52(r11)
 10001d8:   7c 09 03 a6     mtctr   r0
 10001dc:   55 4a 07 fe     clrlwi  r10,r10,31
 10001e0:   4e 80 04 21     bctrl
 10001e4:   80 1f 01 c8     lwz     r0,456(r31)
 10001e8:   7f c4 f3 78     mr      r4,r30
 10001ec:   7c 7d 1b 78     mr      r29,r3
 10001f0:   7f e3 fb 78     mr      r3,r31
 10001f4:   7c 09 03 a6     mtctr   r0
 10001f8:   4e 80 04 21     bctrl
 10001fc:   80 1f 01 ac     lwz     r0,428(r31)
 1000200:   7f 84 e3 78     mr      r4,r28
 1000204:   7f e3 fb 78     mr      r3,r31
 1000208:   7c 09 03 a6     mtctr   r0
 100020c:   4e 80 04 21     bctrl
 1000210:   7f e3 fb 78     mr      r3,r31
 1000214:   83 ff 00 40     lwz     r31,64(r31)
 1000218:   7f e9 03 a6     mtctr   r31
 100021c:   4e 80 04 21     bctrl
 1000220:   80 01 00 44     lwz     r0,68(r1)
 1000224:   7f a3 eb 78     mr      r3,r29
 1000228:   7f 6d db 78     mr      r13,r27
 100022c:   bb 21 00 24     lmw     r25,36(r1)
 1000230:   38 21 00 40     addi    r1,r1,64
 1000234:   7c 08 03 a6     mtlr    r0
 1000238:   4e 80 00 20     blr
 100023c:   80 1f 02 3c     lwz     r0,572(r31)
 1000240:   3c 80 00 03     lis     r4,3
 1000244:   7f e3 fb 78     mr      r3,r31
 1000248:   60 84 80 0e     ori     r4,r4,32782
 100024c:   3b a0 00 14     li      r29,20
 1000250:   7c 09 03 a6     mtctr   r0
 1000254:   4e 80 04 21     bctrl
 1000258:   4b ff ff a4     b       10001fc <_start+0x188>

0100025c <main>:
 100025c:   94 21 ff e0     stwu    r1,-32(r1)
 1000260:   93 e1 00 1c     stw     r31,28(r1)
 1000264:   7c 3f 0b 78     mr      r31,r1
 1000268:   38 00 00 00     li      r0,0
 100026c:   7c 03 03 78     mr      r3,r0
 1000270:   81 61 00 00     lwz     r11,0(r1)
 1000274:   83 eb ff fc     lwz     r31,-4(r11)
 1000278:   7d 61 5b 78     mr      r1,r11
 100027c:   4e 80 00 20     blr

I did a adiff against the same test compile without -fstack-pointer the difference is as follows and does not seem siginificant!

10.RAM Disk:> diff sp nonsp 
2c2
< x:     file format elf32-amigaos

---
> x2:     file format elf32-amigaos
162,163c162,163
<  100025c: 94 21 ff e0     stwu    r1,-32(r1)
<  1000260: 93 e1 00 1c     stw     r31,28(r1)

---
>  100025c: 94 21 ff f0     stwu    r1,-16(r1)
>  1000260: 93 e1 00 0c     stw     r31,12(r1)

There is test case:

#include <iostream>
#include <chrono>

#if !defined(CONSTEXPR)
#define CONSTEXPR
#endif

using namespace std;

// These literals are available in C++14, so once we require C++14 compilers we can get rid of them here.
// (User-literals need to have a leading underscore so we add it here - the "real" literals don't have underscores).
namespace literals {
namespace chrono_literals {
    CONSTEXPR inline std::chrono::seconds operator"" _s(unsigned long long s)
    {
        return std::chrono::seconds(static_cast<std::chrono::seconds::rep>(s));
    }

    CONSTEXPR std::chrono::milliseconds operator"" _ms(unsigned long long ms)
    {
        return std::chrono::milliseconds(static_cast<std::chrono::milliseconds::rep>(ms));
    }
}
}

If we compile it on gcc4.9.3 on x86 like this:

g++ -std=c++11 -c test.c -o test.o

Then object compiles well.

If we compile it on latest aos4 compiler (but its the same and with previous 4.9.3):

ppc-amigaos-g++ -std=c++11 -c test.c -o test.o

test.c:14:27: error: 'chrono' in namespace 'std' does not name a type
     CONSTEXPR inline std::chrono::seconds operator"" _s(unsigned long long s)
                           ^
test.c:19:20: error: 'chrono' in namespace 'std' does not name a type
     CONSTEXPR std::chrono::milliseconds operator"" _ms(unsigned long long ms)
                    ^

Problem there is ppc-amigaos/include/c++/5.3.0/ppc-amigaos/bits/c++config.h , where we found:

/* Define if C99 types in <stdint.h> should be imported in <tr1/cstdint> in namespace std::tr1. /
/ #undef _GLIBCXX_USE_C99_STDINT_TR1 */

Without that define, we can't compile c++11/chrono based stuff. Once i define it manually in the above file, everything compiles.

Probably, we just can manually change it in the adtools build process ?

That what DeadWood says when he build gcc for aros:

This kind of looks familiar. I think (but I'm not sure) this patch can be related to it:

diff -ruN gcc-4.8.3/libstdc++-v3/include/Makefile.in gcc-4.8.3.aros/libstdc++-v3/include/Makefile.in
--- gcc-4.8.3/libstdc++-v3/include/Makefile.in  2013-07-31 20:29:13.000000000 +0100
+++ gcc-4.8.3.aros/libstdc++-v3/include/Makefile.in 2015-02-26 16:39:08.879698333 +0000
@@ -1536,6 +1536,7 @@
              -e '/^#/s/\(${uppercase}${uppercase}*\)/_GLIBCXX_\1/g' \
              -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
              -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
+       -e 's/_GLIBCXX___AROS__/__AROS__/g' \
              -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
              < $< > $@

As I recall GCC creates defines like _GLIBCXX__AROS__ where it expects functionality to be abled, but this define is not  defined, so I just change it to __AROS__. Again, it might not be it.

Thanks.

i'm trying to compile a cross compiler in a virtual machine and now i'm getting an error on binutils:

gcc -DHAVE_CONFIG_H -I. -I/opt/adtools/binutils/repo/binutils -I. -I/opt/adtools/binutils/repo/binutils -I../bfd -I/opt/adtools/binutils/repo/binutils/../bfd -I/opt/adtools/binutils/repo/binutils/../include -DLOCALEDIR="\"/opt/adtools/native-build/root-cross/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -Wno-switch -Wno-unused -MT bucomm.o -MD -MP -MF .deps/bucomm.Tpo -c -o bucomm.o /opt/adtools/binutils/repo/binutils/bucomm.c /opt/adtools/binutils/repo/binutils/bucomm.c: In function 'set_default_bfd_target': /opt/adtools/binutils/repo/binutils/bucomm.c:159:24: error: 'TARGET' undeclared (first use in this function) const char *target = TARGET;

It seems that the file is not taking care of of config.h file.

I've patched everything, gcc and binutils but now i'm getting this error.
Anyone?

For building latest verions of Webkit engine (used in Odyssey browser), we need to have the thread support compiled in the C++ runtime.

For thread support in C++11 on AROS, dedwood use pthread library created by BSzili. OS4 have our own pthreads.library too, but if there can be any problems with, we can use opensource BSzili's pthreads: https://github.com/BSzili/aros-stuff/tree/master/pthreads , as they well tested on morphos/aros.

Here is AROS diff patch which used to build GCC with enalbed chrono, pthreads (with fixes where is need it), so probably that will help a lot to make it all faster:
https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/tools/crosstools/gcc-4.8.3-aros.diff

When compiling & linking with gcc, I get the following error messages:
ld: cannot find -lgcc
ld: cannot find -lgcc_eh

This fails:
gcc Hello.c -o Hello

Compiling without linking works:
gcc -c Hello.c

...but fails when linking:
gcc -o Hello Hello.o

I'm trying to enable wchar_t compilation in libstdc++ but i don't find where the configure parameter are passed to the configure file. I've tried to add --enable-wchar_t to the main Makefile but it isn't pushed to the libstdc++ configure file.
Any tip?

GNU ld (GNU Binutils) 2.23.2
Copyright 2012 Free Software Foundation, Inc.

AmigaOS4.1FE update 1

I have a project where, on linking, i get an error about a missing libc.so:

Development:Coding/SDK/gcc/ppc-amigaos/bin/ld: warning: libc.so, needed by /SDK/local/newlib/lib/libSDL2.so, not found (try using -rpath or -rpath-link)

Snoopy shows that ld is in fact looking in the wrong path (or so i believe) for libc.so:

16440 : ld : o.k. = GetFilePosition(0x13D86B42) = 1024 [2uS]
16441 : ld : FAIL = Open("SDK:newlib/lib/libc.so",OLD) = [0x00000000] [35uS]
16442 : ld : o.k. = Open("SDK:newlib/lib/libc.a",OLD) = [0x13D86B78] [37uS]
16443 : ld : o.k. = ExamineObject(0x42F3C618) [15uS]

libs.so though, together with all the other libs, reside in SDK:local/newlib/lib (as installed per the SDK installer)

For some reason it also refuses to look into the other subdirs to search for the file (like it does with libSDL2 libs), instead it picks up the static lib and links with that, leading to a crashing exe obviously.

A workaround would be to softlink a libc.so into that directory, but maybe ld needs to be fixed to also look in the local dir.