Re: [gccsdk] gtk glib or gmodule problem

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.

> > 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.
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. In the autobuilder, The symbol
underscore variable was set 'on', which corresponds with 'system
supports dlopen()/dlsym()'.

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?

Thanks, Ron M.





_______________________________________________
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