put libSDL_wos.a in the source folder and dont use -l (CFLAGS),
-L gives path to lib folder only (LDFLAGS), remove that too.

ppc-amigaos-g++ -warpup sdltest2.cpp libSDL-wos.a -o sdltest801.elf

since ppc-amigaos-g++ is also the linker, it 1st build sdltest2.o,
searching for unresolved things and then uses libSDL-wos.a to fillin what is missing in sdltest2.o.
with the wrong order, it may ignore all from libSDL-wos.a, so functions are missing when it goes to sdltest2.o

so the link libs must be placed always at the end of the link object chain.
it's easier when you have a working makefile:
instead of -lauto, try -lamiga , not really sure.

#2) not sure about correct path, but is there anything usefull in:
ppc-gcc-2.95.3-base/ppc-amigaos/lib/ ?

with the 68k toolchain i have something like this, for example:
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libamiga.a

which could be linked in with -lamiga . maybe automaticaly invoced by -noixemul or such options.
dunno exactly the mechanism.

That gives the same longer set of undefined symbols, which might mean that it is linking to the SDL_wos but those are problems in the library itself?

I'll try making a makefile.

ppc-amigaos/lib has:
sdlppc.lib 248692 ----rwed 16-Sep-17 16:38:38
libSDL_wos.a 328396 ----rw-d Yesterday 19:07:47
end.o 874 ----rwed 18-Sep-16 20:26:41
libc.a 241952 ----rwed 18-Sep-16 20:26:41
libcwos.a 249608 ----rwed 18-Sep-16 20:26:41
libm.a 37510 ----rwed 18-Sep-16 20:26:41
libppcamiga.a 21378 ----rwed 18-Sep-16 20:26:41
startup.o 3336 ----rwed 18-Sep-16 20:26:41
startupwos.o 3140 ----rwed 18-Sep-16 20:26:41
libiberty.a 123492 ----rw-d 18-Sep-16 20:26:42
libstdc++.a.2.10.0 853292 ----rw-d 18-Sep-16 20:26:42
ldscripts Dir ----rwed 21-Sep-16 06:48:50
libdllppc.a 11084 ----rw-d 23-Sep-16 18:50:58

read this from 2003:
Elf2exe was mentioned the other day, cannot remember extacly.
does it mean you have to convert the *.o with Elf2exe to make it a finished build?

#1) you can try to find for example the PPCCallOS:
nm -l libppcamiga.a | grep PPCCallOS
if it's included try add to LDFLAGS -lppcamiga

to make it even more weird: while reading i found WarpUP mentioned.
is this the same as WarpOS ?! :D

Yeah so the compiler uses warpcollect2 during linking then dumps out an .elf file which elf2exe2 converts to hunk format. I ah... didn't think to run elf2exe2 on the lib and I don't remember if it did.

I'm pretty sure it did run it on it, elf2exe2 on a different file that was run on it gives the same output:
8.Ram Disk:> elf2exe2 gameppc.dll gameppc.exe
Error: Wrong magic number in ELF-header !
Error: Error processing Elffile !

8.Ram Disk:> elf2exe2 libSDL_wos.a libSDL_wos.lib
Error: Wrong magic number in ELF-header !
Error: Error processing Elffile !

The different naming between WarpUP and WarpOS screws me up all the time.

PPCCallOS isn't in libppcamiga.a

ah, ok. there is not much info available, unfortunately.

#1) StormC4 is still being sold and supported product. too bad.
they also offer the gnu source code of StormC4 i just zoned.

hmm, you may try the other *.a in the lib folder.
there must be something what provides this function, and all the others you have to link with.

#1) those .a are some sort of "special" archive. which hold those *.o objects files of a project.
each of those *.o , or .wo files holds a fucntion, can be extracted, manipulated with objdump.
eg: objdump.exe -f libSDL_wos.a

#2) objdump.exe -a libSDL_wos.a | grep -i flip
--> no result, same for init *hmmm*

others are listed:
take a look to the sdl source tree, you build yesterday,
is there a SDL_Flip.wo in the objects or src folder?

PPCCallOS is found in libc.a and startupwos.o the latter I think is included by the -warpup flag.

Thinking maybe I botched something in compiling the orignal lib here's the output of the make:

no SDL_Init.wo, SDL_Flip.wo so the build of the libsdl is not correct. i would say.?!
or it's a function in one of those .wo ? *i'm confused*

#2) Flip is in SDL_Video.wo:
#2) you may try:
this way the SDL_Flip error should vanish. or something is wrong with the whole build.

elf2exe2/warpcollect is not needed if using latest gcc stuff.

Do a simple intuition window open/close mini program. :bash
Start with the 68k version, then warpos.

Show the assembly output (-S) -o whatever.asm. See the uglyness :evilgrin

I have some of those done in some place. A simple "hello word!" works, an intuition warpos program got in a loop waiting.

I compiled the minigl lib+demos, but only got a grey screen.

If someone could figure out how to redo the whole gcc/g++ binaries for warpos with latest includes something could be done.

By the way, it is possible to use the output gcc object files to work with vbcc vasm/vlink.?
Maybe some serious editing of the raw text assembly could be later used for a proper bin.

can we not just try to compile the stormc4 sources?
or maybe with vbcc and target warpos/warpup ?

ppc-amigaos-g++ -warpup sdltest2.cpp SDL_video.wo SDL_cgxvideo.wo \
SDL_cgximage.wo -o sdltest801.elf
Gives me:

By the way my stupid little test .cpp is:

hmm, there is no SDL_Flip missing anymore?

not sure if it does work this way: put all *.wo from SDl build in same folder:
or move sdltest2.cpp into the sdl_src directory and cd to that folder which holds the *.wo files:
*removed*

Point me at a test.c and I'll try it. I have compiled those Q2 mods with this compiler so it does work on some very large things but there's no intuition stuff in there.

I would think that it's not possible to use this lib.a with VBCC since it's a different compiler and that but Hedeon laughed at my thrashing around and said he'd do the VBCC version.

That's something else I was going to try, since stormC 4 uses GCC as the compiler, though there's also the option to use StormC 3 compiler.

Here's the whole -v output that shows warpcollect is trying to use all the .wo .

storm3 dont use gcc. I tried to build some c++ lightwave stuff with that,
but that did not work. was terrible, IIRC ... I dont want to remember :spin


#1) some intuition examples - source code - you can find here:
Amiga C Tutorial - Programming AmigaOS in C - Opening a Window


#2)
*ohhh* it does work, it seems, cool :D
now the same with the other missing functions :spin

it seems "/gg/lib/gcc-lib/ppc-amigaos/2.95.3/warpcollect" is doing the linking stuff,
which has problem with the libSDL_wos.a file format it seems.
since it does find the missing function in the .wo files *hmmm*

all *.a archive file format, if warpcollect has the same problem with them, as seen with libSDL_wos.a,
they have to get extracted and added with the *.wo "method"

I know this is ridiculous, there must be something else, to prevent using warpcollect.

#3)
what is the "latest gcc stuff", what are you referring to?

ppc-gcc-2.95.3-base.lha /ppc-gcc-2.95.3-base/lib/gcc-lib/ppc-amigaos/2.95.3/specs:
for some reason it is invoked here. warpcollect but _not_ /ade/ppc-amigaos/bin/ld ?
something does call warpcollect, not exactly sure if its using the spec file.

#1) you may try to build the object file only with "-c" option:
and invoke the linker ld manually, but i'm not sure about the syntax. maybe:

Sorry. Still didn't read the whole thread, but some more of it. ;)

Yes. I remember something like elf2exe2 was used to convert the ELF V.4-ABI executable into an AmigaDOS-hunk format file, including a small 68k startup-code to launch the PPC main program(?).

You cannot run elf2exe2 on a library, as it is an archive containing several ELF objects. So there is no ELF-executable header.

Neither can you run it on a DLL (ELF shared object), which also has a different ID in its ELF header.

But you also don't want to do that, as both make no sense at all.


PPCCallOS is PowerUp, not WarpOS! Something seriously went wrong here.

FYI, StormC 3 and StormC 4, although different compilers, have something in common: both generate valid PowerOpen-ABI code and real hunk-format executables. H&P managed to patch the GCC used in StormC 4 that way, which not many of the free GCC-ports did.

I don't know what the -warpup option does, which I saw in some posts. Hopefully it switches to PowerOpen-ABI? Then your only remaining problem would be linking and generating a hunk-format executable.

Your llisting of ppc-amigaos/lib seems to include everything needed. Also the startup codes. startup.o is probably the 68k startup? Theoretically it should be possible to link a WarpOS executable with vlink using your ELF objects (it can also convert leading underscores on the fly).

But when this is really a WarpOS compiler then you should be able to compile a simple WarpOS program, without too much warpcollects and elf2exes... :)

dev/gcc/ppc-gcc-2.95.3-base.lha:
it is really confusing :/

since the source code is available, does it make sense to build it?
--> since it would provide g++ aswell, it does make sense :spin

do you think it will build with vbcc and target warpup/warpos?

Still we don't know what it does. Compile a simple function with and without -warpup and compare the assembler output (-S).

Probably. If you have a lot of time. Also note that this is still an old GCC version (2.95.x, IIRC), which has problems with some modern sources.

I didn't have a look into the source. When it is ANSI/ISO-C with not too much compiler-specific stuff in it - possible. Otherwise it is also possible, but much more work. ;)

I'm aware of the trouble caused by old and new crosscompiler.
maybe someone takes the challenge. :spin

ok, lets see, if something simple gets build for grelbfarlk.