sba1 / adtools Goto Github PK
View Code? Open in Web Editor NEWExperimental GNU toolchain for AmigaOS
Experimental GNU toolchain for AmigaOS
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;
}
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.
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).
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.
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
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.
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.
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).
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.
Does -fstack-protector have any use / function on AmigaOS ie has it been
implmented?
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)
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.
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
diff --git a/native-build/makefile b/native-build/makefile
index f6051e9..bb73e64 100644
--- a/native-build/makefile
+++ b/native-build/makefile
@@ -55,7 +55,7 @@ downloads-done:
wget "$(SDK_URL)" -O downloads/SDK_$(SDK_VERSION).lha
cd downloads && wget -N https://gmplib.org/download/gmp/$(GMP_ARCHIVE)
cd downloads && wget -N http://www.mpfr.org/$(MPFR_ARCHIVE)
- cd downloads && wget -N http://www.multiprecision.org/mpc/download/$(MPC_ARCHIVE)
+ cd downloads && wget -N http://www.multiprecision.org/downloads/$(MPC_ARCHIVE)
touch $@
#
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.
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.
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.
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)
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.
See title.
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'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.
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.
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
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
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
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.
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.
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
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.
Please try this:
cd ram:
makedir test
echo blah > test/blah
rm -rf test
For me, the "rm" command doesn't return.
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.
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.
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.
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
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...
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'
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;
}
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?
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.
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'
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 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
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.
This would enable a more complete toolchain,
Again stable tarball is preferred, would this be possible?
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'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?
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.
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
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;
}
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.