{"id":682,"date":"2022-08-30T15:05:25","date_gmt":"2022-08-30T15:05:25","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2013\/11\/09\/accessing-main-program-global-variables-from-a-dlopened-dynamic-library-in-c-on-os-x-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:05:25","modified_gmt":"2022-08-30T15:05:25","slug":"accessing-main-program-global-variables-from-a-dlopened-dynamic-library-in-c-on-os-x-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2022\/08\/30\/accessing-main-program-global-variables-from-a-dlopened-dynamic-library-in-c-on-os-x-collection-of-common-programming-errors\/","title":{"rendered":"Accessing main program global variables from a dlopen()ed dynamic library in C on OS X-Collection of common programming errors"},"content":{"rendered":"

I am maintaining a small application that has some plugin-like functionality, which is implemented through runtime-loaded dynamic modules.<\/p>\n

Specifically, since it’s a Gtk+ app, I’m using gmodule, but the question applies to dlfcn.h \/ dlopen() based dynamic library loading just as well.<\/p>\n

My main program has a single, global struct variable holding some global information. I want this information to be available to functions defined in the dynamically loaded plugins.<\/p>\n

On Linux, I could just refer to this global variable directly – this works well, and I’m guessing that gcc or the linker take care of exporting the global variables from the main program to dynamic libraries.<\/p>\n

Problem is, this doesn’t work on Mac OS X.<\/p>\n

Is there a way to do this on OS X?<\/p>\n

If not, is there a more “best practice” way to expose global information to dynamically loaded libraries?<\/p>\n

Thanks!<\/p>\n

    \n
  1. \n

    Put the global in main.c and declare it extern in the shared object, and try this:<\/p>\n

    MACOSX_DEPLOYMENT_TARGET=10.3 ld -dylib -undefined dynamic_lookup -o multiply.so multiply.o\n<\/code><\/pre>\n
    or<\/p>\n
    MACOSX_DEPLOYMENT_TARGET=10.3 libtool -dynamic -undefined dynamic_lookup -o multiply.so multiply.o\n<\/code><\/pre>\n
    It worked for me on Mac OS X 10.4<\/p>\n<\/li>\n
  2. \n
    Since you declare<\/p>\n
    int global;\n<\/code><\/pre>\n
    in the multiply.h header, the DLL and main program both have their own copy of it. Instead, declare the global in main.c<\/p>\n
    int global;\n<\/code><\/pre>\n
    and in multiply.c declare it as extern:<\/p>\n
    extern int global;\n<\/code><\/pre>\n
    Now if you link main.cpp with the -rdynamic option, then the executable’s symbols will get exported to the DLL.<\/p>\n
    I tested this under linux and it worked, but I’m afraid I dont have access to test on MacOS. Since your ssample code also didn’t work on linux, I expect this was the problem.<\/p>\n<\/li>\n<\/ol>\n
    Originally posted 2013-11-09 21:38:34. <\/small><\/p>","protected":false},"excerpt":{"rendered":"
    I am maintaining a small application that has some plugin-like functionality, which is implemented through runtime-loaded dynamic modules. Specifically, since it’s a Gtk+ app, I’m using gmodule, but the question applies to dlfcn.h \/ dlopen() based dynamic library loading just as well. My main program has a single, global struct variable holding some global information. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-682","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/682","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=682"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/682\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}