On 31/10/14 21:42, Ron wrote:
> In message <5453CF91.3030400@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> On 31/10/14 01:53, Ron wrote:
>>> Can anyone say what could be causing these errors?
>>>
>>> Running a gtk2 calculater emulator I get:
>>> RISC OS error:
>>> 'has suffered a fatal internal error (Window Manager is currently in
>>> use) and must quit immediately'
>>
>> I would assume that the gtk2 program is a WIMP application, so you would
>> run it as such, ie, from an obey file that sets up the environment
>> (wimpslot, system variables, etc) and then runs the binary.
>> It sounds like you're trying to run it from a taskwindow which is I
>> believe a WIMP task and is why you get the Window Manager in use error.
>
>>
> OK, similar to the way a .sh file can manage a gcc build process.
> Using a nextslot and the *Wimptask command provides the temporary
> traceback window, but I will go the obey file route.
Sometimes, Reporter can be useful for providing 'live' debug info
while a task is running, although it wont display all the program
output, only values that you tell it to. I use these inline functions:
---8<---
/* 32 bit hex to string
* return pointer to terminating null in buffer
*/
static inline char *
hex_to_string(unsigned int v, char *buffer, int l)
{
char *term;
__asm__ volatile (" MOV r0, %1;\n"
" MOV r1, %2;\n"
" MOV r2, %3;\n"
" SWI %[os_converthex8];\n"
" MOV %0, r1;\n"
: "=r" (term)
: "r" (v), "r" (buffer), "rI" (l), [os_converthex8] "i" (0xD4)
: "a1", "a2", "a3", "cc");
return term;
}
/* Signed 32 bit integer to string
* return pointer to terminating null in buffer
*/
static inline char *
sint32_to_string(int v, char *buffer, int l)
{
char *term;
__asm__ volatile (" MOV r0, %1;\n"
" MOV r1, %2;\n"
" MOV r2, %3;\n"
" SWI %[os_convertint4];\n"
" MOV %0, r1;\n"
: "=r" (term)
: "r" (v), "r" (buffer), "rI" (l), [os_convertint4] "i" (0xDC)
: "a1", "a2", "a3", "cc");
return term;
}
static inline void report_text0(const char *s)
{
__asm__ volatile (" MOV r0, %0;\n"
" SWI %[report_text0];\n"
: /* no outputs */
: "r" (s), [report_text0] "i" (0x54C80)
: "a1", "cc");
}
static inline void report_hex(unsigned int v)
{
char buf[12];
hex_to_string(v, buf, 10);
report_text0(buf);
}
static inline void report_dec(int v)
{
char buf[20];
sint32_to_string(v, buf, 20);
report_text0(buf);
}
---8<---
You can even set the colour of the lines so that they stand out better.
If you redirect stdout/stderr to a file, sometimes you can
open and view the file while the program is running (it's a snapshot
rather than a live update), but I think that depends on the filing
system; possibly it only works on hostfs in rpcemu.
>>> And then the TaskWindow outputs:
>>> Using 'dlopen' requires dynamic linking: Success
>>
>> Are you static linking? dlopen doesn't work in static binaries; you have
>> to use dynamic linking. When static linking, the dlopen, dlsym and
>> dlclose functions are dummy versions that return an error like the one
>> above.
>>
>>> (free42bin:134785469): GModule-CRITICAL **: g_module_symbol: assertion
>>> `module != NULL' failed
>> >
>>> (free42bin:134785469): GModule-CRITICAL **: g_module_close: assertion `module != NULL' failed
>>
>> These are the result of dlopen failing.
>>
>>> I've tried a few things in the makefile, but always the same errors.
>>
>> If your program needs to load libraries at runtime using dlopen, then
>> dynamic linking is required.
>>
>> Lee.
>>
>
> Yes everything is /supposed/ to be static.
Do you mean that the project needs to be statically linked for some
reason?
> I'll try --disable-shared on my top level program, before delving into
> the autobuilder libraries. I think it is possible to do a non static
> build with .a libs so just removing .so libs wouldn't serve as a
> safeguard, but it would be nice to have confirmation.
> Somewhere a ldd command was mentioned as showing info.
>
> The libglib2.0 manual sort of says that dlopen() can will be used
> internally for loading modules when statically linking. Maybe this is
> the dummy versions you speak of.
The dummy versions are in the GCCSDK source tree here:
gcc4/riscos/soloader/dynamic/ld.so-1.9.9/d-link/libdl/static.c
When I said that dlopen requires dynamic linking, I meant under
RISC OS specifically. It may well be possible to use it in static
programs under Linux, but I couldn't see how it would work.
Under RISC OS, dynamically linked programs and shared libraries are
registered by SOManager at runtime. That way if you try to dlopen
a library that is already in use, the system will know and use the
copy it already has loaded. That applies to its dependencies as well.
Statically linked binaries are not registered at all. In theory, if
your binary was statically linked against Unixlib and you dlopen a
library that is dynamically linked to Unixlib, then the system will
load Unixlib and you would now have 2 versions with separate data
sections. If you dlopen a library that requires gtk2 (for example),
then again you have a conflict between the version statically linked to
the binary and the shared version loaded by dlopen, not to mention the
dependencies that would be loaded that may also be statically linked
to the binary. It would be quite wasteful of memory too.
So it all gets a bit messy. In the end I decided that if dlopen was
required, then it was easier to just use dynamic linking.
> In the autobuilder, The symbol
> underscore variable was set 'on', which corresponds with 'system
> supports dlopen()/dlsym()'.
AFAIK, the Autobuilder checks if RO_SHAREDLIBS is set to yes and if so
tells configure that dlfcn.h exists and that dlopen is therefore
supported. If RO_SHAREDLIBS is set to no, then Autobuilder sets some
variables that tell configure that dlopen is not supported.
So for dynamic linking you need 'RO_SHAREDLIBS=yes' somewhere, either
at the top of your setvars for that particular package or in a file
called build-setvars in the root of your autobuilder build directory
for all packages.
> The other (maybe unnecessary) complication is that libtdl can be used
> to get dlopen() functionality in static libs,
> It needs initialising in the source somewhere and the linker command
> line has -dlopen 'modulename' added.
>
> Should libtdl be necessary, or what is this 'internal dynamic linking'
> aimed at doing?
libtdl is I believe merely a wrapper around dlopen, dlsym and dlclose
under Linux and their equivalent on other systems, the idea being to
present a consistent interface for all systems. So you still
require an implementation of dlopen, etc. If you dump its symbols with
'nm -Dn', you'll see that dlopen is listed as undefined. Also
'readelf -d' shows libdl as a dynamic dependency.
If you can go the dynamic linking route, then that is the much easier
option; dlopen works well then.
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