Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
81 user(s) are online (65 user(s) are browsing Forums)

Members: 0
Guests: 81

more...

Headlines




« 1 ... 15 16 17 (18)


Re: Porting to AmigaOS4 thread
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4195
@Capehill

Yes...seems it's missing in the makefile

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: Porting to AmigaOS4 thread
Quite a regular
Joined:
2007/2/6 13:57
From Donostia (SPAIN)
Posts: 637
@Raziel

cloned the github you posted.

Tweaked a bit the makefile and (a couple of sources) got a build, but it shows title screen and freezes there :-/ with a GR/crash on decode.c

Makefile I use:
#SDL_CFLAGS := `sdl2-config --cflags`
#SDL_LIBS   := `sdl2-config --libs`


CC := ppc-amigaos-gcc

OS 
:= $(shell uname)

ifeq ($(strip $(OS)),AmigaOS)
    
AMIGADATE = $(shell c:date LFORMAT %d.%m.%Y)
else
    
AMIGADATE = $(shell date +"%-d.%-m.%Y")
endif

INCS = -gstabs -ISDK:Local/newlib/include/SDL2 -D__AMIGADATE__="$(AMIGADATE)" -D__USE_INLINE__
SDL_CFLAGS 
+= $(INCS) -Wall -std=gnu99
SDL_LIBS 
= -athread=native -lmodplug -lSDL2 -lstdc++


BB := decode.c fileio.c game.c level.c objects.c resource.c screen.c sound.c staticres.c tiles.c unpack.c
JA 
:= game.c level.c resource.c screen.c sound.c staticres.c unpack.c

BB_SRCS 
:= $(foreach f,$(BB),bb/$f)
JA_SRCS := $(foreach f,$(JA),ja/$f)
SRCS := $(BB_SRCS) $(JA_SRCS)
OBJS := $(SRCS:.c=.o)
DEPS := $(SRCS:.c=.d)

CPPFLAGS := -Wall -Wpedantic -MMD $(SDL_CFLAGS) -I.

allblues bbja

blues
main.o sys_sdl2.o util.$(BB_SRCS:.c=.o)
    $(
CC) $(LDFLAGS) -$@ $^ $(SDL_LIBS)

bbjamain.o sys_sdl2.o util.$(JA_SRCS:.c=.o)
    $(
CC) $(LDFLAGS) -$@ $^ $(SDL_LIBS)

clean:
    
rm -$(OBJS) $(DEPS)

-include $(
DEPS)

   Report Go to top

Re: Porting to AmigaOS4 thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1335
@Raziel

Quote:

[graphics/opengl/context.cpp:73] scummvm_debug:_ZN6OpenGL9ContextGL10initializeENS_14ContextOGLTypeE()+0x8c (section 12 @ 0x252794)
[graphics/opengl/context.cpp:59] scummvm_debug:_ZN6OpenGL9ContextGL10initializeENS_14ContextOGLTypeE()+0x78 (section 12 @ 0x252780)
[backends/platform/sdl/sdl.cpp:218] scummvm_debug:_ZN11OSystem_SDL11initBackendEv()+0x90 (section 12 @ 0x59B


I did a little bit investigation on this ScummVM with plugins -related problem and it seems that:

With plugins disabled, symbol mini_CurrentContext is "B" type and
with plugins enabled, symbol mini_CurrentContext is "U" type.

You can check this with "nm scummvm | grep mini". If you enable verbose build in config.mk, you can see the difference between build flags.

It seems that for some reason, ScummVM core code is also built with -fPIC and this seems to affect the symbol type. For example I was able to crash one of my SDL test programs by building it with -fPIC and linking dynamically. I would expect that -fPIC was only enabled for library code.

Unfortunately, if you disable -fPIC in config.mk and rebuild graphics/opengl/context.cpp, the next issue will be dynamic_cast DSI.

   Report Go to top

Re: Porting to AmigaOS4 thread
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4195
@Capehill

Hmm, that might have historical reasons, but i don't know.

Maybe i'll go and ask on the ScummVM forums.
I'll see if i can find something in configure too.

EDIT:

configure explicietly only addds it to the flags if plugins (shared builds) are used...strange

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: Porting to AmigaOS4 thread
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4195
@all

I have found a very strange linking error.

I did a test today and tried to compile ScummVM with -Os instead of -O3 and while the static version builds fine and produce a working exe, the shared version error in linking state with thousands (probably one for every source file) undefined references, like so

audio/softsynth/mt32/libmt32.a(SampleRateConverter.o): In function `MT32Emu::SampleRateConverter::getBestAnalogOutputMode(double)':
SampleRateConverter.cpp:(.text+0x90): undefined reference to 
`_restfpr_30_x'
audio/softsynth/mt32/libmt32.a(SampleRateConverter.o): In function `MT32Emu::SampleRateConverter::SampleRateConverter(MT32Emu::Synth&, double, MT32Emu::SamplerateConversionQuality)'
:
SampleRateConverter.cpp:(.text+0x160): undefined reference to `_restfpr_31_x'
audio/softsynth/mt32/libmt32.a(SampleRateConverter.o): In function 
`MT32Emu::SampleRateConverter::getOutputSamples(short*, unsigned int)':
SampleRateConverter.cpp:(.text+0x2f8): undefined reference to `_restgpr_24_x'
gmake: *** [scummvmError 1


I dug a little on the net and found something mentioned from the gcc devs (but it was fixed in 2009 and the rest of the discussion went flying over my head),

Any hints?

Not that it really matters, i probably won't use -Os anyway since the save on binary size is a few tenthousand bytes on a 18 MB binary.

Just want to make sure there isn't something broken in our gcc.


@capehill

One more thing...you mentioned that using MAXPATHLEN might be suboptimal due to the path growing too big for the buffer.
Do you have a more robust solution?

btw: Thank you for still caring for my noob problems


Edited by Raziel on 2021/4/19 16:46:58
_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: Porting to AmigaOS4 thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1335
@Raziel

Quote:

you mentioned that using MAXPATHLEN might be suboptimal due to the path growing too big for the buffer.
Do you have a more robust solution?


I don't remember this issue, could you link the old discussion?

   Report Go to top

Re: Porting to AmigaOS4 thread
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4195
@Capehill

It was part of the (shared build) crash on dynamic_cast on github.
https://github.com/sba1/adtools/issues/77

Check your first comment on Nov 9, 2019

Sorry, long time ago :-/

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: Porting to AmigaOS4 thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1335
@Raziel

Thanks. It seems that my proposal was to make sure that buffer overflow doesn't happen during path concatenation. Snprintf is safer than sprintf because programmer can define the maximum buffer size.

   Report Go to top

Re: Porting to AmigaOS4 thread
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4195
@Capehill

So, snprintf like the current one is safe?

snprintf(bufferMAXPATHLEN"%s (%s)"volNamedevName);


But MAXPATHLEN should be revised?

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: Porting to AmigaOS4 thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1335
@Raziel

Yep, that is safe if buffer capacity is MAXPATHLEN.

Do you have some very long path names or why would you like to modify MAXPATHLEN?

   Report Go to top

Re: Porting to AmigaOS4 thread
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4195
@Capehill

No, not really, the longest I can come up with yet are around 70 chars.

I just though because you mentioned that it may cause a path buffer overflow if patches become too long...tgen again that whole thing was aimed at the printf?

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: Porting to AmigaOS4 thread
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4195
@Capehill


Have you seen this: https://github.com/sba1/adtools/pull/101 ???



_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: Porting to AmigaOS4 thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1335
@Raziel

Wow, very impressive. Patch looks short and simple: I just don't speak GCC and elf enough to understand it yet but I will try :)

   Report Go to top


« 1 ... 15 16 17 (18)



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project