Hi
It looks like the issue is related to the use of fdopen(fd, "w+b") for the temporary file and reading from it after it has been written to. I have been able to come up with a couple of workarounds for libxmp:
- Closing the file handle and opening it again.
- Disabling the file buffering before writing to it.
However the problem seems to be with UnixLib itself and its implementation of file buffering.
Regards
Cameron
On Mon, 7 Jun 2021 at 21:45, Cameron Cawley <ccawley2011@gmail.com> wrote:
HiIn this case, "module" refers to a tracker music file like MOD or S3M, rather than a shared object. All of the depackers are built into the main library, apart from the rar and mo3 depackers, which call an external process using either fork/execvp or popen.RegardsCameronOn Mon, 7 Jun 2021 at 20:52, Lee Noar <lee.noar@sky.com> wrote:On 07/06/2021 19:42, Cameron Cawley wrote:
> Hi
>
> I'm currently investigating why a number of tests in libxmp are failing
> when running on RISC OS. All of them are related to the depackers, which
> use an intermediate temporary file created using mkstemp() and fdopen(),
> however although depacking seems to work, the output file doesn't always
> work when reading it back in. I'm at a bit of a loss as to what's wrong,
> so I would appreciate it if someone more knowledgeable could advise.
>
> For reference: https://github.com/libxmp/libxmp/issues/369
> <https://github.com/libxmp/libxmp/issues/369>
I'm probably way off base, but after a quick look at the stdout, I see a
lot of the fails complain about failing to load a module, could that be
relevant? Is this a dl_open type plugin library that is failing to load?
If not, then what is the nature of the module that is failing to load?
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment