Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
70 user(s) are online (53 user(s) are browsing Forums)

Members: 2
Guests: 68

MickJT, clint, more...

Support us!

Headlines

 
  Register To Post  

« 1 ... 15 16 17 (18) 19 20 21 22 »
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@Capehill

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

Go to top
Re: Porting to AmigaOS4 thread
Just can't stay away
Just can't stay away


See User information
@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)

Go to top
Re: Porting to AmigaOS4 thread
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@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

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@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
Go to top
Re: Porting to AmigaOS4 thread
Just can't stay away
Just can't stay away


See User information
@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?

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@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 :-/

Go to top
Re: Porting to AmigaOS4 thread
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@Capehill

So, snprintf like the current one is safe?

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


But MAXPATHLEN should be revised?

Go to top
Re: Porting to AmigaOS4 thread
Just can't stay away
Just can't stay away


See User information
@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?

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@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?

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@Capehill


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



Go to top
Re: Porting to AmigaOS4 thread
Just can't stay away
Just can't stay away


See User information
@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 :)

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@all

Ok, so here are some questions for all of you AMigaOS4 devs/coders.

I have this piece of code in scummvm
bool AmigaOSFilesystemNode::createDirectory() {
    
warning("AmigaOSFilesystemNode::createDirectory() -> Not supported");
    return 
_bIsValid && _bIsDirectory;
}

see here, line 387

which basically means (what the comment/error message says) that it will error out once there is an access to a non-available directory.

The other day it hit me with that error message, when a game tried to auto-save to a non-existing "saves/" directory.

Though, that code was written way back when AmigaOS4 was still young and many things have changed since.

1) Is creating a directory through a node still unsupported?
1.1) If not, could someone give me an example, please?

2) How would/could i be able to resolve it otherwise, if possible?
2.1) Again, example please as i don't know horse remains about coding for AmigaOS4.

Thank you

Go to top
Re: Porting to AmigaOS4 thread
Just can't stay away
Just can't stay away


See User information
@Raziel

I don't know why creating a directory wouldn't work? Maybe its path need some modifications in worst case?

Here is an example from other project which you cannot directly copy-paste but I hope it helps:

static void CreateDirectory(const char * const name)
    {
        
auto lock IDOS->Lock(nameSHARED_LOCK);
        if (
lock) {
            
logging::Debug("Directory '%s' exists already"name);
            
IDOS->UnLock(lock);
            return;
        }

        
lock IDOS->CreateDir(name);
        if (
lock) {
            
logging::Debug("Directory '%s' created"name);
            
IDOS->UnLock(lock);
        } else {
            
logging::Warning("Failed to create '%s'"name);
        }
    }


So the main things here are the check via Lock() and creation part.

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@Capehill

Thank you.

Will try to understand and adapt for testing.

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@all

General question...

Our OpenGL is kind of v1.3 based, correct?
What features does it lack?
e.g. does it support shaders too (like ogles2?)

Thank you all

Go to top
Re: Porting to AmigaOS4 thread
Just can't stay away
Just can't stay away


See User information
@Raziel

MiniGL lacks frame buffer objects (FBOs) and shaders.

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@Capehill

Oh...
Dann

Thank you

Go to top
Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


See User information
@all

Cross-Compiler questions

1)
I get this warning, which is not true.
How can i work around that to get shared builds?
Quote:

CMake Warning (dev) at CMakeLists.txt:2297 (add_library):
ADD_LIBRARY called with SHARED option but the target platform does not
support dynamic linking. Building a STATIC library instead. This may lead
to problems.


2)
How to enable altivec?
It's always turned off, due to a message telling altivec is not available (on the cross platform not, true, but how can i force-enable that, because i do have altivec on my native paltform)?

3)
I immediately get these errors, how to resolve?
In file included from /amiga/porting/SDL2_GL4ES/include/SDL_log.h:40,
                 
from /amiga/porting/SDL2_GL4ES/src/./SDL_internal.h:120,
                 
from /amiga/porting/SDL2_GL4ES/src/SDL.c:21:
/
amiga/porting/SDL2_GL4ES/include/SDL_stdinc.h:466:49errorunknown type name â€˜wchar_t’
  466 
extern DECLSPEC size_t SDLCALL SDL_wcslen(const wchar_t *wstr);
      |                                                 ^~~~~~~


4)
I thought our gcc11 was c++11 aware?
Quote:

-- Checking if compiler supports C++ unique_ptr - no
CMake Error at CMakeLists.txt:112 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).


5)
Any way to workaround the below?
Quote:

*** Warning: inter-library dependencies are not known to be supported.
*** All declared inter-library dependencies are being dropped.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.


Thanks a lot


Edited by Raziel on 2021/11/5 14:45:05
Go to top

  Register To Post
« 1 ... 15 16 17 (18) 19 20 21 22 »

 




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




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project