[Architecture] Problems with gsettings unit tests

Steven Githens swgithen at mtu.edu
Mon Aug 27 21:22:40 EDT 2012


Hi again,

I think I've fixed this.  So, I was on the right track looking at the 
elf file contents, in that those functions were being linked as C++ 
functions.

After a fair amount of sifting through linker and compiler docs, I found 
that we needed to extern that C include.  I'm *not* sure why it properly 
linked the functions we were already using as C functions, and not those 
from gsettingsschema.h ( which is included by gio.h ), but externing the 
whole lot seems to fix it.

extern "C" {
   #include <gio/gio.h>
}

Kasper: I've submitted a pull request against your testing branch, let 
me know if it works for you.

https://github.com/kaspermarkus/linux/pull/1

This article was pretty helpful looking at the different options for 
C<-->C++ linking:

http://developers.sun.com/solaris/articles/mixing.html

-Steve


On 08/22/2012 12:31 AM, Steven Githens wrote:
> Hi Kasper,
>
> I'm able to reproduce this error, and have done some digging. Not 
> quite there yet, but I think I'm getting close... after digging around 
> on an issue which you're correct... is not turning up many search 
> results.  :)
>
> If you use c++filt on that symbol, it does turn out to be the full 
> correct function signature.
> sgithens at sgithens-VirtualBox:~/code/gpii-stuff/linux/node_modules/gsettingsBridge/nodegsettings/build/Release$ 
> c++filt 
> _Z43g_settings_schema_source_new_from_directoryPKcP22_GSettingsSchemaSourceiPP7_GError
> g_settings_schema_source_new_from_directory(char const*, 
> _GSettingsSchemaSource*, int, _GError**)
>
> I started poking in the nodegsettings_1.o and nodegsettings.node ELF 
> binaries with readelf and noticed the following below.
>
> For some reason, our calls to those g_settings_schema functions ( I 
> tried another function from that header as well ) are getting mangled  
> as if they were C++ functions, whereas all the other C functions ( the 
> gio ones and old standards like fprintf ), just show up unmangled.  
> I'm pretty sure this is what's causing the problem, but I'm not sure 
> why those methods are being mangled in C++ style rather than being 
> left alone like the rest of the C methods.
>
> If anyone has seen this sort of thing before let me know. Otherwise 
> I'll keep investigating it tomorrow.
>
> ( I did try taking out the extra gsettingschema.h include, it gets 
> included by gio.h )
>
> -Steve
>
> See the 4th line for the gsettings schema being mangled c++ style.
>
> [snip]
> 000070bc  00001807 R_386_JUMP_SLOT   00000000   g_type_init
> 000070c0  00006007 R_386_JUMP_SLOT   0000422e _ZN2v811HandleScope5Cl
> 000070c4  00005707 R_386_JUMP_SLOT   00003ffe _ZN2v85LocalINS_5Value
> 000070c8  00001a07 R_386_JUMP_SLOT   00000000 _Z43g_settings_schema_
> 000070cc  00001b07 R_386_JUMP_SLOT   00000000 _ZN2v89UndefinedEv
> 000070d0  00005807 R_386_JUMP_SLOT   0000405c _ZN2v86HandleINS_5Arra
> 000070d4  00003907 R_386_JUMP_SLOT   0000448e _ZN2v86HandleINS_6Stri
> 000070d8  00001c07 R_386_JUMP_SLOT   00000000   _ZN2v85FalseEv
> 000070dc  00001d07 R_386_JUMP_SLOT   00000000 g_settings_get_value
> 000070e0  00001e07 R_386_JUMP_SLOT   00000000 _ZNK2v85Value8ToString
> 000070e4  00007307 R_386_JUMP_SLOT   00003e7a _ZNK2v89ArgumentsixEi
> 000070e8  00008607 R_386_JUMP_SLOT   000043a8 _ZN2v85LocalINS_6Numbe
> 000070ec  00001f07 R_386_JUMP_SLOT   00000000 _ZNK2v85Int325ValueEv
> 000070f0  00002007 R_386_JUMP_SLOT   00000000 _ZN2v86String3NewEPKci
> 000070f4  00004d07 R_386_JUMP_SLOT   000043d2 _ZNK2v86HandleINS_7Int
> 000070f8  00002107 R_386_JUMP_SLOT   00000000   fwrite
> 000070fc  00005207 R_386_JUMP_SLOT   0000431c _ZN2v86HandleINS_5Valu
> 00007100  00002207 R_386_JUMP_SLOT   00000000 _ZNK2v85Value7ToInt32E
> 00007104  00002307 R_386_JUMP_SLOT   00000000 g_settings_set_int
> 00007108  00002407 R_386_JUMP_SLOT   00000000   fprintf
> 0000710c  00002507 R_386_JUMP_SLOT   00000000 _ZN2v811HandleScopeC1E
> 00007110  00002607 R_386_JUMP_SLOT   00000000 g_variant_get_boolean
> 00007114  00002707 R_386_JUMP_SLOT   00000000   __stack_chk_fail
> 00007118  00002807 R_386_JUMP_SLOT   00000000 g_variant_type_peek_st
> 0000711c  00002907 R_386_JUMP_SLOT   00000000   _ZN2v84TrueEv
> 00007120  00008107 R_386_JUMP_SLOT   00003e24 _ZN2v88internal9Intern
> 00007124  00002a07 R_386_JUMP_SLOT   00000000 _Z36g_settings_schema_
> 00007128  00002b07 R_386_JUMP_SLOT   00000000 g_variant_get_double
> 0000712c  00003a07 R_386_JUMP_SLOT   00003fa4 _ZN2v86HandleINS_5Valu
> 00007130  00004e07 R_386_JUMP_SLOT   00003fc0 _ZN2v88internal9Intern
> 00007134  00002c07 R_386_JUMP_SLOT   00000000   g_settings_new
> 00007138  00007007 R_386_JUMP_SLOT   00003ff4 _ZNK2v86HandleINS_9Pri
> 0000713c  00002d07 R_386_JUMP_SLOT   00000000 _ZN2v811HandleScope8Ra
> 00007140  00002e07 R_386_JUMP_SLOT   00000000 _ZN2v811HandleScopeD1E
> 00007144  00005407 R_386_JUMP_SLOT   00004464 _ZN2v86HandleINS_5Arra
> [snip]
>
>
> On 08/13/2012 07:59 AM, Kasper Galschiot Markus wrote:
>> Hi Steve Githens (and everyone),
>>
>> In connection to writing integration tests, I've been working on 
>> adding unit tests for the gsettingshandler. As to be able to run 
>> these tests without messing with the users system, I wanted to add 
>> new gsettings schema and test using these - leaving all other 
>> settings untouched. This has turned out to be not so easy.
>>
>> Adding schemas is done by creating an XML file describing the schema 
>> and then loading it onto the system. To add gsettings schemas 
>> globally you generally need root privileges (which we dont want our 
>> unit tests to rely on). Alternatively, one can provide the file in a 
>> local directory and refer to it using an environment variable, but 
>> attempting to do this in node with child_process.exec's and the like 
>> didn't work out. There are issues with having the same environment 
>> available across calls, etc.
>>
>> So I decided to go about it in the pretty way - doing it all from 
>> node (extending your gsettings bridge and .cc file). I've found the 
>> proper documentation and messed around with it quite a bit, but for 
>> some reason I cannot get the damn thing to work. I get the following 
>> error message:
>>
>> /node: symbol lookup error: 
>> /home/cloud4all/Desktop/cloud4all/linux/node_modules/gsettingsBridge/nodegsettings/build/Release/nodegsettings.node: 
>> undefined symbol: 
>> _Z43g_settings_schema_source_new_from_directoryPKcP22_GSettingsSchemaSourceiPP7_GError
>> /
>> I've been searching the internet extensively, but am unable to figure 
>> out what I'm doing wrong. I should have the function defined 
>> properly, no typo's and the appropriate header present... Steve, 
>> could you perhaps take a look at this and see if you can figure out 
>> what I'm doing wrong. I'd be very happy to get on skype and talk you 
>> through what I've tried, my code changes, etc., if that would be helpful.
>>
>> To run the test (which is right now just a single call to the 
>> function of the bridge creating a new schema), go to 
>> node_modules/gsettingsBridge/tests and run: node gsettingsTests.js
>>
>> My code can be found here: 
>> https://github.com/kaspermarkus/linux/tree/gsettingUniteTests 
>> --(yeah, yeah, should've been unitTests)
>>
>> Thanks,
>> ~Kasper
>>
>> PS: For anyone else who might be interesting in trying it out, keep 
>> in mind that it's linux only and:
>>
>>   * If you make changes to nodegsettings.cc, make sure you compile it
>>     afterwards - go to the nodegsettings dir and run: node-waf clean
>>     configure build
>>   * If you make changes to the schema, go to the test/data dir and
>>     run: glib-compile-schemas ./
>>
>> -- 
>> Kasper Galschiot Markus
>> Research Engineer,
>> Raising the Floor - International,
>> www.raisingthefloor.org
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20120827/59136467/attachment.html>


More information about the Architecture mailing list