GCC 6.2 toolchain for AmigaOS 3 - Page 28

emufan · 22 December 2017, 12:47

updating gcc6, I got this one - using cygwin 32bit:

Code:

./toolchain-m68k --prefix=/opt/m68k-amigaos build

....
In file included from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/include/bits/char_traits.h:420:0,
                 from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/include/std/string:40,
                 from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/src/c++11/compatibility-c++0x.cc:31:
/amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/include/c_global/cstdint:78:11: error: 'uint_least32_t' is already declared in this scope
   using ::uint_least32_t;
           ^~~~~~~~~~~~~~
In file included from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/include/std/system_error:39:0,
                 from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/src/c++11/compatibility-c++0x.cc:32:
/amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/config/os/generic/error_constants.h:99:24: error: 'ENOMSG' was not declared in this scope
       no_message =     ENOMSG,
                        ^~~~~~
make[4]: *** [Makefile:911: compatibility-c++0x.lo] Error 1

bebbo · 22 December 2017, 16:00

Quote:

Originally Posted by emufan

updating gcc6, I got this one - using cygwin 32bit:

Code:

./toolchain-m68k --prefix=/opt/m68k-amigaos build

....
In file included from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/include/bits/char_traits.h:420:0,
                 from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/include/std/string:40,
                 from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/src/c++11/compatibility-c++0x.cc:31:
/amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/include/c_global/cstdint:78:11: error: 'uint_least32_t' is already declared in this scope
   using ::uint_least32_t;
           ^~~~~~~~~~~~~~
In file included from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/include/std/system_error:39:0,
                 from /amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/src/c++11/compatibility-c++0x.cc:32:
/amigaos-cross-toolchain/submodules/gcc-6/libstdc++-v3/config/os/generic/error_constants.h:99:24: error: 'ENOMSG' was not declared in this scope
       no_message =     ENOMSG,
                        ^~~~~~
make[4]: *** [Makefile:911: compatibility-c++0x.lo] Error 1

Are you doint a clean build?
Did you install custom headers into your prefix?
Did you modify headers in your prefix?

cygwin32 build and linux 64 bit is always tested befor pushing (fautomat's job).
You either aren't doing a clean before build, or you have some other headers installed in your prefix.

emufan · 22 December 2017, 16:19

Quote:

Originally Posted by bebbo

Are you doint a clean build?
Did you install custom headers into your prefix?
Did you modify headers in your prefix?

it's kind of update in the existing build folder.
this time nothing changed/fixed in my prefix :/

the damn threads do not work, still crash my system, even using only 2 out of 4 native.
it's not only the shell/cygwin, the damn windows gets unusable, hard reset only.
export SHELL=CMD does not really help, it seems

#0) some of the error messages:

Code:

g++: error: spawn: Permission denied

bash: fork: Permission denied

make[2]: fork: Permission denied

make 2400 fork: child -1 - CreateProcessW failed

#1) i start with a cygwin rebase and do a clean build *argh*

emufan · 22 December 2017, 18:40

the trouble maker is one of my GCHQ/NSA bloatware tools aka firewall/anti virus scanner ...

I went into windows safe mode and now the fun starts.
configure scripts now acts/run like on steroids, this is ridiculous.
20 minutes and the whole toolchain was build.

all went fine, mem.c I can build and the object file now is in the amiga hunk format. very cool

in the given example, are the "-Os -fbaserel" options somehow important?
since it does build without them aswell.

#1) this is somehow related to the above:

Code:

slib4.c:41:1: warning: `__saveds__' attribute is only usable with fbaserel [-Wattributes]

#2) told me to report this:

Code:

m68k-amigaos-g++.exe -noixemul  lib/serv_s.o *.o -o plugin.p \
        -Llib/ lib/server.lib -lamiga
....
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld:
Base symbol for base relative reloc not defined: section .text, reloc to symbol .bss
plugin.p: .bss reloc for .bss is out of range: 00000000
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld:
BFD 2.14b 20170314 (adtools build 20080628) internal error, aborting at
.../amigaos-cross-toolchain/submodules/binutils-2.14/bfd/amigaoslink.c 
line 250 in get_relocated_section_contents

/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld:
Please report this bug.

collect2: error: ld returned 1 exit status
make: *** [Makefile:27: plugin.p] Error 1
...
 Base symbol for base relative reloc not defined: section .text, reloc to symbol _DosBase
plugin.p: COMMON reloc for _DosBase is out of range: 00000000
.../amigaos-cross-toolchain/submodules/binutils-2.14/bfd/amigaoslink.c 
line 250 in get_relocated_section_contents

the objectfile with the _Dosbase related stuf I build with:

Code:

m68k-amigaos-gcc.exe  -noixemul -Os -fbaserel -D__SASC -D_AMIGA -I../include/ -c slib4.c
...
m68k-amigaos-ar.exe cru server.lib  slib1.o slib2.o slib3.o slib4.o

when I build with:

Code:

 m68k-amigaos-gcc.exe  -noixemul -m68020 -D__SASC -D_AMIGA -I../include/ -c slib4.c
slib4.c:41:1: warning: `__saveds__' attribute is only usable with fbaserel [-Wattributes]
...

i get this beauty:

Code:

/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)
  (.text+0x290): undefined reference to `__lconv'

linking with: -lm -lstdc++ -lgcc -lamiga
does not help, and atm, I cannot find the source of the function to build my own.

I found an example for localconv, which gives the same error:

Code:

$ m68k-amigaos-g++.exe -noixemul lconv-test.cpp
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x290):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x29c):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x396):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x3f2):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x3fc):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x402):
more undefined references to `__lconv' follow
collect2: error: ld returned 1 exit status

any idea?

#3) phx wrote something about the HUNK_DEBUG in the .stab section.

bebbo · 23 December 2017, 19:56

Quote:

Originally Posted by emufan

...
in the given example, are the "-Os -fbaserel" options somehow important?
since it does build without them aswell.

It's not important but it shows that __far symbols are not accessed via a4.

Quote:

Originally Posted by emufan

#1) this is somehow related to the above:

Code:

slib4.c:41:1: warning: `__saveds__' attribute is only usable with fbaserel [-Wattributes]

__saveds is used to reload the data address into a4. That mode is only used with -fbaserel(32)

Quote:

Originally Posted by emufan

#2) told me to report this:

Code:

m68k-amigaos-g++.exe -noixemul  lib/serv_s.o *.o -o plugin.p \
        -Llib/ lib/server.lib -lamiga
....
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld:
Base symbol for base relative reloc not defined: section .text, reloc to symbol .bss
plugin.p: .bss reloc for .bss is out of range: 00000000
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld:
BFD 2.14b 20170314 (adtools build 20080628) internal error, aborting at
.../amigaos-cross-toolchain/submodules/binutils-2.14/bfd/amigaoslink.c 
line 250 in get_relocated_section_contents

/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld:
Please report this bug.

collect2: error: ld returned 1 exit status
make: *** [Makefile:27: plugin.p] Error 1
...
 Base symbol for base relative reloc not defined: section .text, reloc to symbol _DosBase
plugin.p: COMMON reloc for _DosBase is out of range: 00000000
.../amigaos-cross-toolchain/submodules/binutils-2.14/bfd/amigaoslink.c 
line 250 in get_relocated_section_contents

please raise a new issue and provide the necessary info to rebuild that problem.

Quote:

Originally Posted by emufan

the objectfile with the _Dosbase related stuf I build with:

Code:

m68k-amigaos-gcc.exe  -noixemul -Os -fbaserel -D__SASC -D_AMIGA -I../include/ -c slib4.c
...
m68k-amigaos-ar.exe cru server.lib  slib1.o slib2.o slib3.o slib4.o

when I build with:

Code:

 m68k-amigaos-gcc.exe  -noixemul -m68020 -D__SASC -D_AMIGA -I../include/ -c slib4.c
slib4.c:41:1: warning: `__saveds__' attribute is only usable with fbaserel [-Wattributes]
...

i get this beauty:

Code:

/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)
  (.text+0x290): undefined reference to `__lconv'

linking with: -lm -lstdc++ -lgcc -lamiga
does not help, and atm, I cannot find the source of the function to build my own.

I found an example for localconv, which gives the same error:

Code:

$ m68k-amigaos-g++.exe -noixemul lconv-test.cpp
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x290):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x29c):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x396):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x3f2):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x3fc):
undefined reference to `__lconv'
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libnix/libnix.a(setlocale.o)(.text+0x402):
more undefined references to `__lconv' follow
collect2: error: ld returned 1 exit status

any idea?

__lconv was not picked up by the linker, since the inclustion trigger did not consider common symbols.

This is fixed now.

Quote:

Originally Posted by emufan

#3) phx wrote something about the HUNK_DEBUG in the .stab section.

Vlink's problem is not the HUNK_DEBUG, it's the HUNK_RELOC32 for the HUNK_DEBUG.

cla · 23 December 2017, 20:27

This tool chain is really nice work!!! Still no plans for a stable branch on github?

emufan · 23 December 2017, 20:42

Quote:

Originally Posted by bebbo

It's not important but it shows that __far symbols are not accessed via a4.

__saveds is used to reload the data address into a4. That mode is only used with -fbaserel(32)

hmm, ok. complicated stuff

Quote:

Vlink's problem is not the HUNK_DEBUG, it's the HUNK_RELOC32 for the HUNK_DEBUG.

ok, allright - even more technical stuff

Quote:

__lconv was not picked up by the linker, since the inclustion trigger did not consider common symbols.

This is fixed now.

ok, time to reboot in win safe mode again

Quote:

please raise a new issue and provide the necessary info to rebuild that problem.

i've attached the source.
1) goto source folder -> make
2) cd ../
3) make
the _Dosbase reloc error is listed.

emufan · 23 December 2017, 21:44

Quote:

Originally Posted by bebbo

__lconv was not picked up by the linker, since the inclustion trigger did not consider common symbols.

This is fixed now.

I removed everything but got an error when building libnix:

Code:

m68k-amigaos-ar -q libnix.a assert/__eprintf.o ctype/_ctype_.o
ctype/isalnum.o ctype/isalpha.o ctype/isblank.o ctype/iscntrl.o
ctype/isdigit.o ctype/isgraph.o ctype/islower.o ctype/isprint.o
ctype/ispunct.o ctype/isspace.o
....
time/time.o

m68k-amigaos-ranlib libnix.a
make[2]: *** [../../sources/nix/Makefile:61: libnix.a] Aborted
(core dumped)
make[2]: *** Deleting file 'libnix.a'
make[2]: Leaving directory '/amigaos-cross-toolchain/.build-m68k
build/libnix/lib/nix'
make[1]: *** [/amigaos-cross-toolchain/.build-m68k/build/libnix/
sources/Makefile:38: nix] Error 2
make[1]: Leaving directory '/amigaos-cross-toolchain/.build-m68k/
build/libnix/lib'
make: *** [Makefile:45: all] Error 2
ERROR: command "make LD=m68k-amigaos-ld CC=m68k-amigaos-gcc
RANLIB=m68k-amigaos-ranlib AS=m68k-amigaos-as AR=m68k-amigaos-ar
CPP=m68k-amigaos-gcc -E -j4" failed with 2

win7 cygwin32 - "error 2, core dumped" - not much info, but maybe you find the issue.

Fook42 · 23 December 2017, 22:25

Hello..
it seems the current repo is broken.. i'm facing this problem although i was able to build the gcc without any problem 6 month ago.

my computer is a virtual-box running 32Bit Lubuntu 16.04.3 LTS.

The Build.log is attached as zip - i hope this helps somehow?

Code:

m68k-amigaos-ranlib libnix.a
*** Error in `m68k-amigaos-ranlib': double free or corruption (!prev): 0x08971b28 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x67377)[0xb75b2377]
/lib/i386-linux-gnu/libc.so.6(+0x6d2f7)[0xb75b82f7]
/lib/i386-linux-gnu/libc.so.6(+0x6dc31)[0xb75b8c31]
m68k-amigaos-ranlib[0x8072d04]
m68k-amigaos-ranlib[0x80554ca]
m68k-amigaos-ranlib[0x8055970]
m68k-amigaos-ranlib[0x804ab35]
m68k-amigaos-ranlib[0x804b15b]
m68k-amigaos-ranlib[0x8049e36]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xb7563637]
m68k-amigaos-ranlib[0x8049351]
======= Memory map: ========
08048000-08087000 r-xp 00000000 08:01 420379     /opt/m68k6x-amigaos/bin/m68k-amigaos-ranlib
08087000-08088000 r--p 0003e000 08:01 420379     /opt/m68k6x-amigaos/bin/m68k-amigaos-ranlib
08088000-08089000 rw-p 0003f000 08:01 420379     /opt/m68k6x-amigaos/bin/m68k-amigaos-ranlib
08089000-0808b000 rw-p 00000000 00:00 0 
0896d000-08b3b000 rw-p 00000000 00:00 0          [heap]
b7400000-b7421000 rw-p 00000000 00:00 0 
b7421000-b7500000 ---p 00000000 00:00 0 
b754b000-b76fb000 r-xp 00000000 08:01 133425     /lib/i386-linux-gnu/libc-2.23.so
b76fb000-b76fd000 r--p 001af000 08:01 133425     /lib/i386-linux-gnu/libc-2.23.so
b76fd000-b76fe000 rw-p 001b1000 08:01 133425     /lib/i386-linux-gnu/libc-2.23.so
b76fe000-b7701000 rw-p 00000000 00:00 0 
b7706000-b7722000 r-xp 00000000 08:01 131136     /lib/i386-linux-gnu/libgcc_s.so.1
b7722000-b7723000 rw-p 0001b000 08:01 131136     /lib/i386-linux-gnu/libgcc_s.so.1
b7723000-b7726000 rw-p 00000000 00:00 0 
b7726000-b7728000 r--p 00000000 00:00 0          [vvar]
b7728000-b7729000 r-xp 00000000 00:00 0          [vdso]
b7729000-b774b000 r-xp 00000000 08:01 132910     /lib/i386-linux-gnu/ld-2.23.so
b774b000-b774c000 rw-p 00000000 00:00 0 
b774c000-b774d000 r--p 00022000 08:01 132910     /lib/i386-linux-gnu/ld-2.23.so
b774d000-b774e000 rw-p 00023000 08:01 132910     /lib/i386-linux-gnu/ld-2.23.so
bfa66000-bfa87000 rw-p 00000000 00:00 0          [stack]
../../sources/nix/Makefile:59: recipe for target 'libnix.a' failed
make[2]: *** [libnix.a] Aborted (core dumped)
make[2]: *** Deleting file 'libnix.a'
make[2]: Leaving directory '/home/renef/AMIGA/new/amigaos-cross-toolchain/.build-m68k/build/libnix/lib/nix'
/home/renef/AMIGA/new/amigaos-cross-toolchain/.build-m68k/build/libnix/sources/Makefile:38: recipe for target 'nix' failed
make[1]: *** [nix] Error 2
make[1]: Leaving directory '/home/renef/AMIGA/new/amigaos-cross-toolchain/.build-m68k/build/libnix/lib'
Makefile:43: recipe for target 'all' failed
make: *** [all] Error 2
ERROR: command "make LD=m68k-amigaos-ld CC=m68k-amigaos-gcc RANLIB=m68k-amigaos-ranlib AS=m68k-amigaos-as AR=m68k-amigaos-ar CPP=m68k-amigaos-gcc -E -j8" failed with 2

bebbo · 24 December 2017, 11:22

Quote:

Originally Posted by emufan

hmm, ok. complicated stuff

ok, allright - even more technical stuff

ok, time to reboot in win safe mode again

i've attached the source.
1) goto source folder -> make
2) cd ../
3) make
the _Dosbase reloc error is listed.

Code:

m68k-amigaos-g++: error: lib/serv_s.o: No such file or directory
m68k-amigaos-g++: error: lib/server.lib: No such file or directory

emufan · 24 December 2017, 13:07

Quote:

Originally Posted by bebbo

Code:

m68k-amigaos-g++: error: lib/serv_s.o: No such file or directory
m68k-amigaos-g++: error: lib/server.lib: No such file or directory

these you build in the "source" folder:
1) qemloss-WIP.zip --> qemloss-WIP/source/ --> make
--> will build serv_s.o using vasm and server.lib using m68k-amigaos-gcc
--> will copy result to ../lib

Code:

qemloss-WIP.zip --> qemloss-WIP/source/Makefile:
...
	m68k-amigaos-ar.exe cru server.lib slib1.o slib2.o slib3.o slib4.o
	m68k-amigaos-ranlib.exe server.lib

	vasm -m68020 -Fhunk serv_s.a -o serv_s.o	
	-cp server.lib serv_s.o ../lib/

this is LW-SDK stuff, startup code for any plugin you build for lightwave.
slib4.c has the "_Dosbase" stuff.

2) qemloss-WIP.zip --> qemloss-WIP/ --> make
--> will compile qemloss files and link with lib/serv_s.o and lib/server.lib
to create the final qemloss.p plugin

Fook42 · 24 December 2017, 13:33

another error that occurs since last changes yesterday (?)

i removed the whole directory-tree and did a git clone .. and after running the toolchain-script this output is shown:

Code:

amigaos-cross-toolchain$ ./toolchain-m68k --prefix=/opt/m68k6x-amigaos --threads 1 build
DEBUG: enter directory ".build-m68k/archives"
INFO: already done "m4-1.4.17.tar.gz-fetch"
INFO: already done "gawk-3.1.8.tar.gz-fetch"
INFO: already done "autoconf-2.13.tar.gz-fetch"
INFO: already done "bison-1.35.tar.gz-fetch"
INFO: already done "texinfo-4.12.tar.gz-fetch"
INFO: already done "automake-1.15.tar.gz-fetch"
INFO: already done "flex-2.5.4.tar.gz-fetch"
INFO: already done "NDK-3.9.lha-fetch"
INFO: already done "libamiga.tar.gz-fetch"
INFO: already done "libm-5.4.tar.gz-fetch"
INFO: already done "ixemul-48.2.lha-fetch"
INFO: already done "vasm.tar.gz-fetch"
INFO: already done "vlink.tar.gz-fetch"
INFO: already done "vbcc.tar.gz-fetch"
INFO: already done "ira.lha-fetch"
INFO: already done "vdam68k.tar.gz-fetch"
INFO: already done "vclib.lha-fetch"
DEBUG: execute "git submodule init"
DEBUG: execute "git submodule update"
fatal: reference is not a tree: 268f7957b77bb2598494f88819f554a7e32d7fa2
Unable to checkout '268f7957b77bb2598494f88819f554a7e32d7fa2' in submodule path 'submodules/binutils-2.14'
ERROR: command "git submodule update" failed with 1

phx · 25 December 2017, 11:59

Quote:

Originally Posted by bebbo

Vlink's problem is not the HUNK_DEBUG, it's the HUNK_RELOC32 for the HUNK_DEBUG.

Not really.

The problem is that HUNK_DEBUG cannot stand alone. It needs to be attached to a HUNK_CODE, HUNK_DATA or HUNK_BSS segment, like HUNK_RELOC32, HUNK_SYMBOL, etc..

bebbo · 25 December 2017, 18:54

Quote:

Originally Posted by phx

Not really.

The problem is that HUNK_DEBUG cannot stand alone. It needs to be attached to a HUNK_CODE, HUNK_DATA or HUNK_BSS segment, like HUNK_RELOC32, HUNK_SYMBOL, etc..

1. who defines that HUNK_DEBUG "cannot stand alone"?
2. where is a a HUNK_DEBUG that is standalone?
3. who defines that there must be only one HUNK_DEBUG? Consider supporting different debuggers from one object file.

phx · 25 December 2017, 19:51

Quote:

Originally Posted by bebbo

1. who defines that HUNK_DEBUG "cannot stand alone"?

Several sources. For example "The Amiga Guru Book", section 22.1. And any AmigaOS linker and hunk tool which fails processing such object files.

Quote:

2. where is a a HUNK_DEBUG that is standalone?

In the example hexdump which emufan provided here: http://eab.abime.net/showpost.php?p=...9&postcount=20
I can clearly see:

Code:

...
HUNK_NAME ".data
HUNK_DATA (6 long words)
HUNK_END

HUNK_NAME ".bss"
HUNK_BSS (1 long word)
HUNK_END

HUNK_NAME ".stab"
HUNK_DEBUG (12 long words)
HUNK_RELOC32
HUNK_END
...

A segment ends with HUNK_END. So HUNK_DEBUG stands alone without any code/data/bss segment specification.

Quote:

3. who defines that there must be only one HUNK_DEBUG?

Multiple HUNK_DEBUG for a segment could be allowed. I seem to remember that SAS/C also used multiple of them. Best known was the "LINE" debug hunk.

Quote:

Consider supporting different debuggers from one object file.

Sure, as long as the structure is not completely illegal.

bebbo · 25 December 2017, 21:43

Quote:

Originally Posted by phx

Several sources. For example "The Amiga Guru Book", section 22.1. And any AmigaOS linker and hunk tool which fails processing such object files.

...

Sure, as long as the structure is not completely illegal.

I think I'm understanding what you mean with standalone and so on. And your wording is too harsh, there is nothing 'illegal'.

So there is an argument to change the object file structure. But a linker which cannot handle that kind of content, will not create working executables, since these DEBUG_HUNKs are containg the infos for aliases, constructors etc. p.p - only gcc knows...

(BTW: slink does not complain and links - omitting the DEBUG_HUNKS)

Thank you for telling me.

bebbo · 26 December 2017, 00:03

Quote:

Originally Posted by emufan

these you build in the "source" folder:
1) qemloss-WIP.zip --> qemloss-WIP/source/ --> make
--> will build serv_s.o using vasm and server.lib using m68k-amigaos-gcc
--> will copy result to ../lib

Code:

qemloss-WIP.zip --> qemloss-WIP/source/Makefile:
...
    m68k-amigaos-ar.exe cru server.lib slib1.o slib2.o slib3.o slib4.o
    m68k-amigaos-ranlib.exe server.lib

    vasm -m68020 -Fhunk serv_s.a -o serv_s.o    
    -cp server.lib serv_s.o ../lib/

this is LW-SDK stuff, startup code for any plugin you build for lightwave.
slib4.c has the "_Dosbase" stuff.

2) qemloss-WIP.zip --> qemloss-WIP/ --> make
--> will compile qemloss files and link with lib/serv_s.o and lib/server.lib
to create the final qemloss.p plugin

You have to pass -fbaserel to the linker, since there are baserel files:

Code:

 m68k-amigaos-g++.exe -noixemul  lib/serv_s.o 3D.o AdjModel.o AdjPrims.o  Hash.o Heap.o Matrix.o ProxGrid.o Quadrics.o qemloss.o Decimate.o -o qemloss.p         -Llib/ lib/server.lib -lm -lstdc++ -lgcc -lamiga -fbaserel

Then linking succeeds.

Fook42 · 26 December 2017, 15:52

hello bebbo

first of all, thanks for your work even though it's x-mas !

do you have any idea, why i am facing the git-errors i mentioned some posts ago ? maybe i'm doing something wrong, but i dont know what.

regards,
fook42

phx · 26 December 2017, 16:18

Quote:

Originally Posted by bebbo

And your wording is too harsh, there is nothing 'illegal'.

Ok, you are right. There is nothing which explicitely calls such a structure being illegal. Nevertheless it is... not correct.

What kind of executable should a linker create from such an object? Unlike ELF (.debug*) the hunk-format has no segments which are ignored by the loader. Which means, assuming a linker would emit such an executable, it had to include a segment with only HUNK_DEBUG and RELOC32 in it.

When you look at the AmigaOS LoadSeg() code you see that it only recognizes HUNK_CODE/DATA/BSS hunks as the basis for a subsequent relocation hunk. So your plan to make the OS relocate a HUNK_DEBUG won't work. And even if this is not your plan and you want to relocate the DEBUG hunk with your debugger instead, my guess would be that the system will crash, because there is no valid pointer in the loader's segment table when encountering these relocations.

Quote:

a linker which cannot handle that kind of content, will not create working executables, since these DEBUG_HUNKs are containg the infos for aliases, constructors etc. p.p - only gcc knows...

Are you saying the executable code depends on information from a DEBUG hunk? That's really strange. Such information should be for a debugger only, and can usually be stripped without a problem.

Otherwise, then I don't understand why it should be a DEBUG hunk at all. When the program needs it, put it into HUNK_DATA.

(I have the feeling there are many misunderstandings, but I didn't read anything in this thread before my first post).

Quote:

(BTW: slink does not complain and links - omitting the DEBUG_HUNKS)

I didn't expect that, but you are right! It strips everything, though, also the HUNK_RELOC32. Which is sort of good, so the executable doesn't crash. BLink behaves the same, which doesn't surprise much.

To write something constructive: I need an idea how a working executable has to look for you, then maybe we can think about what an object file needs.

bebbo · 26 December 2017, 19:21

Quote:

Originally Posted by Fook42

hello bebbo

first of all, thanks for your work even though it's x-mas !

do you have any idea, why i am facing the git-errors i mentioned some posts ago ? maybe i'm doing something wrong, but i dont know what.

regards,
fook42

try

Code:

git pull
git submodule foreach git pull

are there errors with these commands?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
New GCC based dev toolchain for AmigaOS 3.x	cla	Coders. Releases	8	24 December 2017 10:18
Issue with photon/xxxx WinUAE Toolchain	arpz	Coders. Asm / Hardware	2	26 September 2015 22:33
New 68k gcc toolchain	arti	Coders. C/C++	17	31 July 2015 03:59
Hannibal's WinUAE Demo Toolchain 5	Bobic	Amiga scene	1	23 July 2015 21:04
From gcc to vbcc.	Cowcat	Coders. General	9	06 June 2014 14:45

23 December 2017, 20:27	#546
cla dev Join Date: Aug 2014 Location: Copenhagen Age: 48 Posts: 65	This tool chain is really nice work!!! Still no plans for a stable branch on github?

26 December 2017, 15:52	#558
Fook42 Registered User Join Date: Aug 2016 Location: germany Posts: 67	hello bebbo first of all, thanks for your work even though it's x-mas ! do you have any idea, why i am facing the git-errors i mentioned some posts ago ? maybe i'm doing something wrong, but i dont know what. regards, fook42

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)