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

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.

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 :guru

#0) some of the error messages:
#1) i start with a cygwin rebase and do a clean build *argh*

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 :spin

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:
#2) told me to report this:
the objectfile with the _Dosbase related stuf I build with:
when I build with:
i get this beauty:
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:
any idea?


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

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)

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

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

This is fixed now.

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

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

hmm, ok. complicated stuff :spin

ok, allright - even more technical stuff :spin
ok, time to reboot in win safe mode again :D
i've attached the source.
1) goto source folder -> make
2) cd ../
3) make
the _Dosbase reloc error is listed.

I removed everything but got an error when building libnix:
win7 cygwin32 - "error 2, core dumped" - not much info, but maybe you find the issue.

broken gcc-build
 

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?

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
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 :)

git checkout error
 

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:

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.

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

In the example hexdump which emufan provided here: http://eab.abime.net/showpost.php?p=...9&postcount=20
I can clearly see:
A segment ends with HUNK_END. So HUNK_DEBUG stands alone without any code/data/bss segment specification.

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.

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.

You have to pass -fbaserel to the linker, since there are baserel files:
Then linking succeeds.

hello bebbo

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

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

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.

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).


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.

try
are there errors with these commands?