[gccsdk] Investigating failure with libxmp tests

Cameron Cawley ccawley2011 at gmail.com
Mon Jun 7 13:45:23 PDT 2021


In 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.


On Mon, 7 Jun 2021 at 20:52, Lee Noar <lee.noar at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riscos.info/pipermail/gcc/attachments/20210607/15ef03ef/attachment.html>

More information about the gcc mailing list