Hi 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.
Regards Cameron On Mon, 7 Jun 2021 at 20:52, Lee Noar <lee.n...@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
_______________________________________________ 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
