Porting to AmigaOS4 thread

@all

Does this look familiar to any of you?
One of the ScummVM maintainers was upgrading his toolchain for the automatic buildbot and compiled an AmigaOS4 exe (both static and .so), unfortunately both of the exes crash with the same error.

Here it is:

Now...it "looks" familiar to me, i guess i have seen it a long time ago when i tried to compile it myself, but can't for the life of me remember what i did wrong to trigger that crash.

Does anyone hvae an idea?

Thanks in advance

@Raziel

According to a web search, symbol might be "operator delete". Strange issue though. I had some issues (don't recall details) when linking ScummVM dynamically but static build solved those.

If this happens also on a static build, then it's really strange, because everything should be linked to the executable.

@Capehill

I *think* i know those kind of things too when i tried to switch to dynamic builds...but i also remember that i had fixed those with providing the corred .so's.

Might as well be that the second build was also a shared build...

@all

to all you sed gurus.

What line could i use to change

" [here] (NEWS.md)."

to

@{"NEWS.md" link NEWS.md/main}.

Where NEWS.md should be a variable as there are more than this one on the text and it should be changed globally accordingly.

I tried some combinations but i can't get my head around sed's syntax.

TIA

@Raziel

Quote:Me neither - sed is sick (getting flameproof coat ).

Personally, I'd whip up a little ARexx script to do it instead.

Best regards,

Niels

@nbache

I have done that in my script.
It's three lines, but beforehand runs a sed script which does all the preliminary work and which would spare me those three lines.

I know it's not something huge, but i want to learn

@all

OK, so now i am completely puzzled as to how a linker line has to look.

My LDFLAGS look like this

-athread=native -Wl,-no-keep-memory -L/sdk/local/newlib/lib

Now, do i need a double minus or a single minus after that -Wl, (which, if i read that correctly, is some sort of grouping commands together)?
Could i add the -athread also to the -Wl, part?

Where can i find a LD documentation that covers OUR version of LD (there is none in the SDK)?

I have now seen both versions all over the net and don't know which is correct.

Since stupid LD doesn't complain with either of them, i'm lost.

Help!

edit: OK, reading through the online manual tells that two minus`are correct.

Has anyone tried to port Syndicate wars?

http://swars.vexillium.org/

@all

Does anyone know of a working profiler?

Hieronymous unfortunately doesn't run on X1000 hw.

The gcc -pg flag crashes my system, so gprof is no option either...

@Raziel

Hieronymous didn't also work on Sam440 when I tried it.

But please explain what you are planning to do with a profiler? Are you trying to sample a program that you compile yourself?

@Capehill

I did a port of liba52 which can decode AC3 or Dolby Digital audio/video.
While i know that this eats *a lot* of cpu power (even though liba52 is built to be fast) i'm a little disappointed on it's performance in ScummVM (there is one game for now that uses it to display alternate videos/sound).

The video/sound plays, but with dropouts and slowdowns, so i asked for help on the ScummVM forums.
They pointed me towards doing a profiling of the game in question and see where the slowdown comes from, liba52 (bad luck, nothing can be done about it, apart from gfx hardware rendering, i assume) or within the ScummVM code (which "could" be solved, or at least enhanced, probably).

Since i have never done any profiling i wanted to try it, but alas, i'm stuck.

Arrgh, i hate makefiles

I try to port a static library, but it seems i have only one stupid mistake in, since i can create the .a file, but it only consists of
Quote:
None of the needed source files are compiled in it seems, no matter what i try.

Here's the stripped down makefile, since i need to keep it as easy to understsnd as i can


Can someone please point out the obvious mistake?
I can't...

With the above makefile the source files are compiled, but the "ar" linker doesn't seem to pick them up. Why?

@Raziel

Quote:

should be

Quote:

@salass00

wrt the option --no-keep-memory

https://linux.die.net/man/1/ld tells that it actually does use two dashes, but i'm not sure if it has any effect whatsoever on AmigaOS4 since i can't seems to distinguish any chanmges in memory consumption when using or avoiding this.

@BSzili

/me hugs BSzili

@Salas00 (and others too of course)

Meet today with another problem:



While first part is fine, second one, with "wostream" didn't works , same "wostream not a member of std::". Maybe have any idea how to replace it to make it still works ?


Also there is some strange issue with previous "wstring" defination. There is test case which fail very heavy:



Bring lot's of error from bits/hashtable.h.

Replacing <wchar_t> on <char> make it compiles, but not sure if that fits.

Also, it works when i trying to compile it as it (with wchar_t) , but over clib2. Its with newlib such issue.

@kas1e
I don't think there's any wide string support, at least in newlib. Speaking of to_string, some time ago I found a cleaner workaround. It's actually in the headers, but you have to define _GLIBCXX_USE_C99_STDIO (or _GLIBCXX_USE_C99 on MorphOS).

@BSzili
Sadly but to_string with this project i am working on didn't cause any issues :(

Its about that wstring .. In all other cases, that "typedef basic_string<wchar_t> wstring;" did the trick (at least all compiles and works). Its just when it used with unordered_map it bring compiling errors..

@BSzili
What is interesting is that both , and issue with std::wostream and that issue with wstring+unordered_map didn't happens if i use CLIB2.

What mean that probabaly with newlib it also can compiles, just need some dance with includes, and probably setting come compiler flags.

All those wstring and wostream come with gcc itself (and in their includes), not in clib2 or newlib. Just seems clib2 is better handle it all via their own includes/ifdefs, etc.


EDIT: for wostream and wostringstream going the same way as with wstring:



Seems all compiles fine.

Need only understand how to deal with that strange issue when such a typedefes wstring used together with unordered_map. It bring some strange issue from /bits/hashtable.h, saying:



But with clib2 all fine.

@all

Can shared objects be stripped?
Is the command the same?

strip libsomelib.so -o libstripped.so ?

I'm asking because i tried to strip a shared object and it was not usable afterwards?
But it "should" work, shouldn't it?

Maybe there is a special flag i need to use with the strip command?