libntfs_ext library compilation with cellsdk

Code:
CELL_MK_DIR = $(CELL_SDK)/samples/mk

include $(CELL_MK_DIR)/sdk.makedef.mk

PPU_INCDIRS +=        -Iinclude
PPU_SRCS =        $(wildcard source/*.c) $(wildcard source/libext2fs/*.c)

PPU_LIB_TARGET =    libntfs_ext.a

#PPU_LDLIBS :=        -lio -lsysutil -lm -llv2

MACHDEP :=        -DBIGENDIAN

GCC_PPU_CFLAGS +=    -O2 -Wall -mcpu=cell $(MACHDEP) -fno-strict-aliasing -DPS3_GEKKO -DHAVE_CONFIG_H -DPS3_STDIO


.PHONY: verbose

verbose:
    make VERBOSE=1

include $(CELL_MK_DIR)/sdk.target.mk
 
Just looked at the project again, now I remember what gave me grief back in August...
The reent.h header in iosupport.h, I simply couldn't find an equivalent in cellsdk back then...

In ntfsinternal.h
#include <lv2/mutex.h>
is replaced by
#include <sys/synchronization.h>
And the
sysLwMutexLock/sysLwMutexUnlock
get replaced by
sys_lwmutex_lock/sys_lwmutex_unlock

But then we get this reent.h problem in iosupport.h & I fear that needs rewritten...

Any suggestions guys?
 
Bring it localn something like that : https://github.com/Zarh/libntfs_ext/commit/edecd7d3311707747924fdb7a8437ba6aee7742b

I didn't include pwd.h and grp.h but it can be done with same methode ... do not hesitate tu pull a request in github with your stuff.

I know my 'method' is ugly but later when it will work it can be cleaned ^^'
Thanks Zar, that was helpful.
I made a fork of libntfs_ext from estwald's git. I wanted to start from scratch to make something clear and easy to modify.
https://github.com/freddy38510/libntfs_ext

At this moment, the library can be compiled with cellsdk without errors. There are some warnings, if anybody wants to fix this it will be good.
Code:
warning: cast to pointer from integer of different size

The next step is to test the functions of the library in a simple cellsdk project.
 
  • Like
Reactions: Zar
Thanks Zar, that was helpful.
I made a fork of libntfs_ext from estwald's git. I wanted to start from scratch to make something clear and easy to modify.
https://github.com/freddy38510/libntfs_ext

At this moment, the library can be compiled with cellsdk without errors. There are some warnings, if anybody wants to fix this it will be good.
Code:
warning: cast to pointer from integer of different size

The next step is to test the functions of the library in a simple cellsdk project.
Actually iirc the best version might have been from andoma who corrected a few bugs in the library for use with movian...
Check his github.
 
id like to get in on this. i have the fedora setup from joonies guide, is that good enough? which repo would be the best to clone?
 
id like to get in on this. i have the fedora setup from joonies guide, is that good enough? which repo would be the best to clone?
At this stage, use freddy38510's repo as it compiles.
Any machine with cellsdk installed will do just fine. Fedora is often the easiest to setup..
 
Yes he did.
He ported it to v1 toolchain for sdk compatibility with movian compilation. Otherwise people would have needed 2 sdk...

But he also fixed some serious bugs though iirc. Check the commits...
If I am right, we may want to include those as well.
 
Last edited:
But he also fixed some serious bugs though iirc. Check the commits...
If I am right, we may want to include those as well.
I will look at the commits to add the fixes into my repo.
Thanks bguerville for your suggestion.

What is the best way to let people contribute to the project ?
I made a develop branch to allow contributors to pull requests and let the master branch clean until the requests are reviewed/discussed/approved . I also granted push access to @Zar and @bguerville

I'm still new to git, so i'm not sure about this.
 
I merged Andoma commits into my repo, keeping psl1ght v2 and cellsdk compatibility.

I tried to compile an elf file with the library and i've got this error returned by "ps3ppuld.exe" :
Code:
reference to undefined symbol `__syscalls' in file libntfs_ext.a(ps3_io.ppu.o)

I looked in README_PS3.txt file and found this
Now the library support some standard I/O function. By default PS3_STDIO is defined and ps3_io.c
compiles this support defining libc syscalls function from the __syscalls struct
NOTE: including sys/mutext.h and sys/syscalls.h, it cause an error because sys_mutex_attr is re-defined. For this
reason i define struct __syscalls_t directly and maybe you needs to do soe changes if you are using a different newlib

I think we need to rewrite the __syscalls struct. My knowledges about C are not sufficient for this task.

What do you think about that guys ?
 
I'll try to fix it, can you upload me your sample plz ? perhaps, you can upload it in github.
Yes i will do that. Actually i can't access to my PC. Tomorrow will be fine i think (I live in France).

It's just a simple cellsdk project to make an elf file. The main.c file simply call one function from libntfs_ext.a library. I also linked the library and included ntfs.h file header of course.
 
@Zar
This last commit was fixing a number of compilation warnings right?

Is this__syscalls struct to be redefined linked to the reentrant syscalls bullshit again....?
Can anyone explain why there is no such stuff in ps3sdk? How is it handled originally?
Especially with Psl1ght being just an unfinished rip-off of ps3sdk with many things missing, not added....
 
@Zar
This last commit was fixing a number of compilation warnings right?
Yes, i just compiled and there is only one warning left in unistr.c file.

@ZarIs this__syscalls struct to be redefined linked to the reentrant syscalls bullshit again....? Can anyone explain why there is no such stuff in ps3sdk? How is it handled originally? Especially with Psl1ght being just an unfinished rip-off of ps3sdk with many things missing, not added....
This is what i think, maybe i'm wrong. The best thing would be to find a way to avoid the use of the reentrancy. I don't understand very well the mechanism behind that and how cellsdk works for reentrancy.
 
I have been testing too.

1 warning left during compilation.

Trying to use the library atm gives a few undefined symbol __syscalls errors then undefined symbol .panic...

I am not sure about reentrant syscalls either. That's what bothered me most before when I looked into the port...
 
Last edited:

Similar threads

Back
Top