GCC user DLL init/exit function ? - OS2

This is a discussion on GCC user DLL init/exit function ? - OS2 ; Does anyone know how the init/exit function prototypes for a GCC DLL and how they need be implemented (e.g. runtime init)? Unfortunately every compiler seems to do it differently. Fortunately for IBM VAC and OpenWatcom there is good documentation but ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: GCC user DLL init/exit function ?

  1. GCC user DLL init/exit function ?

    Does anyone know how the init/exit function prototypes for a
    GCC DLL and how they need be implemented (e.g. runtime init)?

    Unfortunately every compiler seems to do it differently.
    Fortunately for IBM VAC and OpenWatcom there is good documentation
    but not for GCC. I guess the cross-platform manual does not really
    help here because this is platform specific behavior, at least
    I couldn't find anything.

    IBM VAC:
    extern "C" unsigned long _System _DLL_InitTerm( unsigned long hmod, unsigned long termination )
    (C++ Runtime must be manually initialized)

    OpenWatcom:
    extern "C" unsigned _System LibMain( unsigned hmod, unsigned termination )

    GCC:
    ??????


    I really need the module handle, so implementing a static object
    that gets created at load time is not sufficient.

  2. Re: GCC user DLL init/exit function ?

    On 09/20/08 06:04 pm, Heiko Nitzsche wrote:
    > Does anyone know how the init/exit function prototypes for a
    > GCC DLL and how they need be implemented (e.g. runtime init)?
    >
    > Unfortunately every compiler seems to do it differently.
    > Fortunately for IBM VAC and OpenWatcom there is good documentation
    > but not for GCC. I guess the cross-platform manual does not really
    > help here because this is platform specific behavior, at least
    > I couldn't find anything.


    For EMX there is not too bad documentation. IIRC in
    http://hobbes.nmsu.edu/download/pub/...9d/emxview.zip you
    will find emxlib.inf that covers most of the EMX based functions.
    emxdev.inf also has some info on flags and stuff. klibc has symplified a
    lot of the emx way but still good to look at sometimes.

    >
    > IBM VAC:
    > extern "C" unsigned long _System _DLL_InitTerm( unsigned long hmod,
    > unsigned long termination )
    > (C++ Runtime must be manually initialized)
    >
    > OpenWatcom:
    > extern "C" unsigned _System LibMain( unsigned hmod, unsigned termination )
    >
    > GCC:


    unsigned long _DLL_InitTerm (unsigned long mod_handle, unsigned long flag);

    > ??????
    >
    >
    > I really need the module handle, so implementing a static object
    > that gets created at load time is not sufficient.


    Dave

  3. Re: GCC user DLL init/exit function ?

    > For EMX there is not too bad documentation. IIRC in
    > http://hobbes.nmsu.edu/download/pub/...9d/emxview.zip you
    > will find emxlib.inf that covers most of the EMX based functions.
    > emxdev.inf also has some info on flags and stuff. klibc has symplified a
    > lot of the emx way but still good to look at sometimes.


    Thanks for the pointer. I'll have a look at it.

    >> GCC:

    >
    > unsigned long _DLL_InitTerm (unsigned long mod_handle, unsigned long flag);


    Based on the EMX doc it luckily seems to mimic the behavior of IBM C/Set and VAC.


    I have now almost all GBM modules and apps compiling with GCC 3.3.5.
    There is only a minor link problem with weak SOM symbol warnings in
    the Lucide GBM plugin left which I hope to find a solution for.

    Because of the errors with the OS/2 Toolkit headers I sticked with
    the EMX header file. I had to do only minor changes in the code because
    of different data type defintions are used in the prototypes for the REXX
    function handler definition.

    Thanks,
    Heiko

  4. Re: GCC user DLL init/exit function ?

    On Sun, 21 Sep 2008 01:04:45 UTC, Heiko Nitzsche wrote:

    > I really need the module handle, so implementing a static object
    > that gets created at load time is not sufficient.


    Is that the only reason you need the _DLL_InitTerm()? If so, use
    DosQueryModFromEIP() instead.

    > There is only a minor link problem with weak SOM symbol warnings
    > in the Lucide GBM plugin left which I hope to find a solution for.


    Which symbols? Most of the warnings are meaningless and are easy
    to resolve. Post a list of your errors - I may have some fixes.


    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


  5. Re: GCC user DLL init/exit function ?

    >> I really need the module handle, so implementing a static object
    >> that gets created at load time is not sufficient.

    >
    > Is that the only reason you need the _DLL_InitTerm()? If so, use
    > DosQueryModFromEIP() instead.


    Yeah, together with a static class instance this might work.
    I could do all the initialization of the plugin environment
    (for Lucide and Mozilla) in the constructor but I could not
    easily prevent the dll from being loaded if some problems
    are detected.

    The function seems to be only available for Warp 4.5x or was
    it just not documented earlier? I'd like to keep support for
    Warp 3 and 4.

    As I wrote in the other answer, the mechanism is identical to
    the IBM VAC one and thus I just had to enable it also for GCC.

    >> There is only a minor link problem with weak SOM symbol warnings
    >> in the Lucide GBM plugin left which I hope to find a solution for.

    >
    > Which symbols? Most of the warnings are meaningless and are easy
    > to resolve. Post a list of your errors - I may have some fixes.


    This would be great!

    That's the current state:
    -------------------------
    sc -c -s"xc;xih;xh" -Iludoc lugbm.idl
    sominc\cnvsomex.cmd lugbm.xh
    g++ -c -Wall -I. -I..\..\gbm -I..\common -Iludoc -Isominc -mcpu=i686 -m32 -O3 -Zomf -DOS2 -DNDEBUG lugbm.cpp
    In file included from lugbm.cpp:131:
    lugbm.xih:164: warning: `LuGbmDocumentClassData' initialized and declared
    `extern'
    lugbm.xih:169: warning: `LuGbmDocumentCClassData' initialized and declared
    `extern'
    g++ -c -Wall -I. -I..\..\gbm -I..\common -Iludoc -Isominc -mcpu=i686 -m32 -O3 -Zomf -DOS2 -DNDEBUG WGbmDocument.cpp
    g++ -Zmt -Zomf -Zlinker /NOE -Zlinker /NOI -Zlinker /ALIGN:4 -Zlinker /EXEPACK:2 -Zlinker /OPTFUNC -Zlinker /PACKCODE -Zli
    nker /PACKDATA -Zdll -o lugbm.dll lugbm.o WGbmDocument.o lugbm_gcc.def -L..\..\gbm -lgbmmem.lib -lgbmscale.lib -lgbmmir.lib -lgbmr
    ect.lib -l..\common\common.lib -lludoc\ludoc.lib -lsomtk
    weakld: error: Unresolved symbol (UNDEF) '_LuDocumentNewClass'.
    weakld: info: The symbol is referenced by:
    H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o
    weakld: error: Unresolved symbol (UNDEF) '_somParentNumResolve'.
    weakld: info: The symbol is referenced by:
    H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o
    weakld: error: Unresolved symbol (UNDEF) '_somBuildClass'.
    weakld: info: The symbol is referenced by:
    H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o
    Ignoring unresolved externals reported from weak prelinker.

    H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lug bm.o) : error LNK2029: "_LuDocumentNewClass" : unresolved external
    H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lug bm.o) : error LNK2029: "_somParentNumResolve" : unresolved external
    H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lug bm.o) : error LNK2029: "_somBuildClass" : unresolved external


    I couldn't find a warning suppression for the lugbm.xih issues.

    ILINK 5.0 links all after I added to the .def file:


    IMPORTS
    _LuDocumentNewClass=ludoc.LuDocumentNewClass
    _LuPixbufNewClass=ludoc.LuPixbufNewClass
    _somParentNumResolve=som.somParentNumResolve
    _somBuildClass=som.somBuildClass

    EXPORTS
    LuGbmDocumentNewClass=_LuGbmDocumentNewClass
    LuGbmDocumentClassData=_LuGbmDocumentClassData
    LuGbmDocumentCClassData=_LuGbmDocumentCClassData


    All of the related code is generated by sc and thus I guess some
    kind of massage afterwards would be needed.

    The plugin itself so far seems to work correctly.


    BTW, I uploaded the new GBM modules (1.61) to my homepage yesterday.
    The source package contains everything to build with GCC 3.3.5 CSD3
    except the ILINK 5.0 version which I grabbed from the Mozilla site.
    I couldn't get the VAC 3.08 ILINK working under the gcc linker.
    The binaries are still build with OpenWatcom, thus no libc06.dll
    is required. When built with GCC it is required.



  6. Re: GCC user DLL init/exit function ?

    [A complimentary Cc of this posting was sent to
    Heiko Nitzsche
    ], who wrote in article <48d7f7cb$0$16888$9b4e6d93@newsspool1.arcor-online.net>:
    > >> I really need the module handle, so implementing a static object
    > >> that gets created at load time is not sufficient.

    > >
    > > Is that the only reason you need the _DLL_InitTerm()? If so, use
    > > DosQueryModFromEIP() instead.

    >
    > Yeah, together with a static class instance this might work.


    In C, I just use a pointer to itself.

    > I could do all the initialization of the plugin environment
    > (for Lucide and Mozilla) in the constructor but I could not
    > easily prevent the dll from being loaded if some problems
    > are detected.
    >
    > The function seems to be only available for Warp 4.5x or was
    > it just not documented earlier? I'd like to keep support for
    > Warp 3 and 4.


    It is in Warp3 (at least after some very early fixpak).

    > As I wrote in the other answer, the mechanism is identical to
    > the IBM VAC one and thus I just had to enable it also for GCC.


    Just in case, below is the code used for one of my versions of dlopen():

    Hope this helps,
    Ilya

    ================================================== =====

    static ULONG retcode;
    static char fail[300];

    static ULONG dllHandle;
    static char dllname[80];
    static int handle_found;
    static int handle_loaded;

    #ifdef DLOPEN_INITTERM
    unsigned long _DLL_InitTerm(unsigned long modHandle, unsigned long flag)
    {
    switch (flag) {
    case 0: /* INIT */
    /* Save handle */
    dllHandle = modHandle;
    handle_found = 1;
    return TRUE;

    case 1: /* TERM */
    handle_found = 0;
    dllHandle = (unsigned long)NULLHANDLE;
    return TRUE;
    }

    return FALSE;
    }

    #endif

    HMODULE
    find_myself(void)
    {

    static APIRET APIENTRY (*pDosQueryModFromEIP) (HMODULE * hmod, ULONG * obj, ULONG BufLen, PCHAR Buf,
    ULONG * Offset, ULONG Address);
    HMODULE doscalls_h, mod;
    static int failed;
    ULONG obj, offset, rc;
    char buf[260];

    if (failed)
    return 0;
    failed = 1;
    doscalls_h = (HMODULE)dlopen("DOSCALLS",0);
    if (!doscalls_h)
    return 0;
    /* {&doscalls_handle, NULL, 360}, */ /* DosQueryModFromEIP */
    rc = DosQueryProcAddr(doscalls_h, 360, 0, (PFN*)&pDosQueryModFromEIP);
    if (rc)
    return 0;
    rc = pDosQueryModFromEIP(&mod, &obj, sizeof(buf), buf, &offset, (ULONG)dlopen);
    if (rc)
    return 0;
    failed = 0;
    handle_found = 1;
    dllHandle = mod;
    return mod;
    }

    void *
    dlopen(char *path, int mode)
    {
    HMODULE handle;
    char tmp[260], *beg, *dot;
    ULONG rc;
    unsigned fpflag = _control87(0,0);

    fail[0] = 0;
    if (!path) { /* Our own handle. */
    if (handle_found || find_myself()) {
    if (handle_loaded)
    return (void*)dllHandle;
    rc = DosQueryModuleName(dllHandle, sizeof(dllname), dllname);
    if (rc) {
    strcpy(fail, "can't find my DLL name by the handle");
    retcode = rc;
    return 0;
    }
    rc = DosLoadModule(fail, sizeof fail, dllname, &handle);
    if (rc) {
    strcpy(fail, "can't load my own DLL");
    retcode = rc;
    return 0;
    }
    handle_loaded = 1;
    goto ret;
    }
    retcode = ERROR_MOD_NOT_FOUND;
    strcpy(fail, "can't load from myself: compiled without -DDLOPEN_INITTERM");
    return 0;
    }
    if ((rc = DosLoadModule(fail, sizeof fail, path, &handle)) == 0)
    goto ret;

    retcode = rc;

    /* Not found. Check for non-FAT name and try truncated name. */
    /* Don't know if this helps though... */
    for (beg = dot = path + strlen(path);
    beg > path && !strchr(":/\\", *(beg-1));
    beg--)
    if (*beg == '.')
    dot = beg;
    if (dot - beg > 8) {
    int n = beg+8-path;
    memmove(tmp, path, n);
    memmove(tmp+n, dot, strlen(dot)+1);
    rc = DosLoadModule(fail, sizeof fail, tmp, &handle);
    if (rc == 0)
    goto ret;
    retcode = rc;
    }
    handle = 0;

    ret:
    _control87(fpflag, MCW_EM); /* Some modules reset FP flags on load */
    return (void *)handle;
    }

  7. Re: GCC user DLL init/exit function ?

    On Mon, 22 Sep 2008 19:53:47 UTC, Heiko Nitzsche wrote:

    > > If so, use DosQueryModFromEIP() instead.

    >
    > The function seems to be only available for Warp 4.5x or was
    > it just not documented earlier? I'd like to keep support for
    > Warp 3 and 4.


    It's been around forever. AFAICT, system exception handlers use
    it to identify the module where the crash occurred.

    > As I wrote in the other answer, the mechanism is identical to
    > the IBM VAC one and thus I just had to enable it also for GCC.


    If you already have the code in place, there's no reason to change it.

    > >> There is only a minor link problem with weak SOM symbol warnings
    > >> in the Lucide GBM plugin left which I hope to find a solution for.

    >
    > lugbm.xih:164: warning: `LuGbmDocumentClassData' initialized and declared
    > `extern'


    I never generate .xih files. Do they get passthru lines from the .idl
    file the same as .ih files do? For instance:

    This line in the IDL:
    passthru C_ih_after = "#define foo 1"

    Produces this line in the .IH:
    /*
    * Passthru lines: File: "C.ih", "after"
    */
    #define foo 1

    If so, in the "after" section, you might '#undef SOMEXTERN', then redefine
    it without the 'extern'. FYI... the "after" lines appear after other
    headers have been included, so this fix should only affect that file.

    > weakld: error: Unresolved symbol (UNDEF) '_LuDocumentNewClass'.
    > weakld: error: Unresolved symbol (UNDEF) '_somParentNumResolve'.
    > weakld: error: Unresolved symbol (UNDEF) '_somBuildClass'.
    > Ignoring unresolved externals reported from weak prelinker.
    >
    > H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lug bm.o) : error LNK2029:
    > "_LuDocumentNewClass" : unresolved external
    > H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lug bm.o) : error LNK2029:
    > "_somParentNumResolve" : unresolved external
    > H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lug bm.o) : error LNK2029:
    > "_somBuildClass" : unresolved external


    As I'm sure you've recognized, none of these functions should be decorated
    with an underscore. I think the problem is in somltype.h where SOMLINK
    is defined. For the compilers it knows about, it assigns a value
    (e.g. _System or _syscall) - for the rest, it's blank. Lacking any explicit
    linkage directives, gcc appears to be making them cdecl which is close
    enough to _System for the code to work (once you get past the name mangling).

    Somewhere before the headers are included, you can add this (if passthru
    lines work, you can put it in the idl's 'passthru C_ih_before' section):

    #ifdef __EMX__
    #ifdef SOMLINK
    #undef SOMLINK
    #endif
    #define SOMLINK _System
    #endif

    BTW... I use the v3.0 toolkit's SOM headers to avoid an incompatibility
    with versions of Warp 3 prior to FP16. Consequently, the definition of
    SOMLINK may be in a different file or be laid-out differently in your
    headers.



    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


  8. Re: GCC user DLL init/exit function ?

    >>>> There is only a minor link problem with weak SOM symbol warnings
    >>>> in the Lucide GBM plugin left which I hope to find a solution for.

    >> lugbm.xih:164: warning: `LuGbmDocumentClassData' initialized and declared
    >> `extern'

    >
    > I never generate .xih files. Do they get passthru lines from the .idl
    > file the same as .ih files do? For instance:
    >
    > This line in the IDL:
    > passthru C_ih_after = "#define foo 1"
    >
    > Produces this line in the .IH:
    > /*
    > * Passthru lines: File: "C.ih", "after"
    > */
    > #define foo 1
    >
    > If so, in the "after" section, you might '#undef SOMEXTERN', then redefine
    > it without the 'extern'. FYI... the "after" lines appear after other
    > headers have been included, so this fix should only affect that file.


    Yeah, great! It helped and all warnings are gone now.

    I did the following:

    implementation
    {
    passthru C_xih_after = "#include ";
    ...

    and the included header file contains:

    #ifdef SOMEXTERN
    #undef SOMEXTERN
    #endif
    #define SOMEXTERN

    > #ifdef __EMX__
    > #ifdef SOMLINK
    > #undef SOMLINK
    > #endif
    > #define SOMLINK _System
    > #endif
    >
    > BTW... I use the v3.0 toolkit's SOM headers to avoid an incompatibility
    > with versions of Warp 3 prior to FP16. Consequently, the definition of
    > SOMLINK may be in a different file or be laid-out differently in your
    > headers.


    The Lucide plugin toolkit already contains a modified version of the
    SOM headers to support OpenWatcom and according to the readme also GCC
    (which figured out was not fully the case). So instead of the above proposal
    I simply corrected somltype.h in the Lucide toolkit so that SOMLINK _System
    is now also used for EMX.

    I'll send the changes to the Lucide developers so that they can update
    the Lucide plugin toolkit on the Netlabs website.


    Finally both changes (especially the first one with SOMEXTERN) resolved
    also all other problems that existed with OpenWatcom and IBM VAC exports.
    I could get rid of all explicit SOM related exports from the .def files

    So, many many thanks!!!

    I'll update the GBM source package on my GBM website probably tomorrow and
    upload the packages then to Hobbes.


  9. Re: GCC user DLL init/exit function ?

    On Tue, 23 Sep 2008 01:47:54 UTC, Heiko Nitzsche wrote:

    > I could get rid of all explicit SOM related exports from the .def files


    A SOM dll is *supposed* to contain these exports in the .def file

    EXPORTS
    LuGbmDocumentNewClass
    LuGbmDocumentClassData
    LuGbmDocumentCClassData

    Under normal circumstances, they enable the SOM Class Manager to
    load & construct a class. Perhaps your setup is non-standard and
    doesn't explicitly need them, but I wouldn't leave them out.


    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


  10. Re: GCC user DLL init/exit function ?

    >> I could get rid of all explicit SOM related exports from the .def files
    >
    > A SOM dll is *supposed* to contain these exports in the .def file
    >
    > EXPORTS
    > LuGbmDocumentNewClass
    > LuGbmDocumentClassData
    > LuGbmDocumentCClassData
    >
    > Under normal circumstances, they enable the SOM Class Manager to
    > load & construct a class. Perhaps your setup is non-standard and
    > doesn't explicitly need them, but I wouldn't leave them out.


    OK, I'll put them back. Thanks for the pointer.

  11. Re: GCC user DLL init/exit function ?

    >> A SOM dll is *supposed* to contain these exports in the .def file
    >>
    >> EXPORTS
    >> LuGbmDocumentNewClass
    >> LuGbmDocumentClassData
    >> LuGbmDocumentCClassData
    >>
    >> Under normal circumstances, they enable the SOM Class Manager to
    >> load & construct a class. Perhaps your setup is non-standard and
    >> doesn't explicitly need them, but I wouldn't leave them out.

    >
    > OK, I'll put them back. Thanks for the pointer.


    Mmmh, these exports don't seem to exist anymore:

    weakld: error: Unresolved symbol (UNDEF EXPORT) 'LuGbmDocumentCClassData'.
    weakld: info: The symbol is referenced by:
    H:/GBM_SVN/rb1.61/gbmplugins/gbmlucide/lugbm_gcc.def
    weakld: error: Unresolved symbol (UNDEF EXPORT) 'LuGbmDocumentClassData'.
    weakld: info: The symbol is referenced by:
    H:/GBM_SVN/rb1.61/gbmplugins/gbmlucide/lugbm_gcc.def
    Ignoring unresolved externals reported from weak prelinker.
    ILink : error LNK2022: LuGbmDocumentClassData (alias LuGbmDocumentClassData) : export undefined
    ILink : error LNK2022: LuGbmDocumentCClassData (alias LuGbmDocumentCClassData) : export undefined

  12. Re: GCC user DLL init/exit function ?

    On Tue, 23 Sep 2008 06:58:50 UTC, Heiko Nitzsche wrote:

    > >> A SOM dll is *supposed* to contain these exports in the .def file
    > >>
    > >> EXPORTS
    > >> LuGbmDocumentNewClass
    > >> LuGbmDocumentClassData
    > >> LuGbmDocumentCClassData

    >
    > Mmmh, these exports don't seem to exist anymore:
    >
    > weakld: error: Unresolved symbol (UNDEF EXPORT) 'LuGbmDocumentCClassData'.
    > weakld: info: The symbol is referenced by:
    > H:/GBM_SVN/rb1.61/gbmplugins/gbmlucide/lugbm_gcc.def
    > weakld: error: Unresolved symbol (UNDEF EXPORT) 'LuGbmDocumentClassData'.
    > weakld: info: The symbol is referenced by:
    > H:/GBM_SVN/rb1.61/gbmplugins/gbmlucide/lugbm_gcc.def
    > Ignoring unresolved externals reported from weak prelinker.
    > ILink : error LNK2022: LuGbmDocumentClassData (alias LuGbmDocumentClassData) :
    > export undefined
    > ILink : error LNK2022: LuGbmDocumentCClassData (alias LuGbmDocumentCClassData) :
    > export undefined


    If you're absolutely certain your class will never be used for any other
    purpose, you might decide to ignore the issue. However, since these
    exports *should* exist, it suggests that one of the modifications you
    made is in error - and could come back to bite you in a future version.
    Consequently, it might be worth a little time to pursue what is currently
    a non-issue.

    My *guess* is that the problem is here:

    > #ifdef SOMEXTERN
    > #undef SOMEXTERN
    > #endif
    > #define SOMEXTERN


    The relevant part of the original definition is this:

    #ifdef __cplusplus
    #define SOMEXTERN extern "C"
    #endif

    In getting rid of the 'extern' you also got rid of the '"C"' and
    probably ended up with name-mangled versions of these structures.


    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


  13. Re: GCC user DLL init/exit function ?

    I'd really like to get the correct also with GCC.

    That's the important part of what was generated by sc for the API:
    ------------------------------------------------------------------
    /* A procedure to create the LuGbmDocument Class */
    SOMEXTERN SOMClass * SOMLINK LuGbmDocumentNewClass(
    integer4 majorVersion,
    integer4 minorVersion);

    /* The API to the LuGbmDocument class object, and the methods it introduces. */
    SOMEXTERNS struct LuGbmDocumentClassDataStructure {
    SOMClass *classObject;
    } SOMDLINK LuGbmDocumentClassData;
    #define _LuGbmDocument LuGbmDocumentClassData.classObject

    /* The API to parentMtabs for LuGbmDocument, and the instance data it introduces. */
    SOMEXTERNS struct LuGbmDocumentCClassDataStructure {
    somMethodTabs parentMtab;
    somDToken instanceDataToken;
    } SOMDLINK LuGbmDocumentCClassData;


    SOMEXTERN is defined as extern "C" here but it only affects
    LuGbmDocumentNewClass. LuGbmDocumentNewClass is correctly
    exported without _ with all 3 compilers, probably because SOMLINK
    is also defined as _System. SOMDLINK is empty.

    Also both structs are correctly exported with IBM VAC and OpenWatcom,
    only GCC causes them to have the underscore. The map files show this.

    For VAC and OpenWatcom SOMEXTERNS is defined also as extern "C"
    but GCC doesn't like this which is probably why SOMEXTERNS is
    defined in somltype.h for it just as extern. And here the problem
    may start:

    #ifndef SOMEXTERNS
    #ifdef __GNUC__
    #define SOMEXTERNS extern
    #else
    #define SOMEXTERNS extern "C"
    #endif
    #endif

    I also tried to set SOMDLINK to _System which is of course complained.

    So it looks like a problem with GCC. I have no further idea how
    the problem could be resolved.

    Because both, LuGbmDocumentClassData and LuGbmDocumentCClassData are
    just structs, wouldn't it be sufficient to map the names in .def file?
    Name mangling or linkage shouldn't have an effect here or am I wrong?

    EXPORTS
    LuGbmDocumentNewClass
    LuGbmDocumentClassData=_LuGbmDocumentClassData
    LuGbmDocumentCClassData=_LuGbmDocumentCClassData


    That's the current of the source package I have re-uploaded.


  14. Re: GCC user DLL init/exit function ?

    On 09/23/08 06:14 pm, Heiko Nitzsche wrote:
    >
    > So it looks like a problem with GCC. I have no further idea how
    > the problem could be resolved.


    You might want to ask on the libc users list. Perhaps Knut remembers why
    he did things like this and the best way around...

    >
    > Because both, LuGbmDocumentClassData and LuGbmDocumentCClassData are
    > just structs, wouldn't it be sufficient to map the names in .def file?
    > Name mangling or linkage shouldn't have an effect here or am I wrong?
    >
    > EXPORTS
    > LuGbmDocumentNewClass
    > LuGbmDocumentClassData=_LuGbmDocumentClassData
    > LuGbmDocumentCClassData=_LuGbmDocumentCClassData
    >
    >
    > That's the current of the source package I have re-uploaded.


    I've used alias's like this a few times without ill affects. Though
    never with C++ code yet.
    Dave

  15. Re: GCC user DLL init/exit function ?

    On Wed, 24 Sep 2008 01:14:37 UTC, Heiko Nitzsche wrote:

    > For VAC and OpenWatcom SOMEXTERNS is defined also as extern "C"
    > but GCC doesn't like this which is probably why SOMEXTERNS is
    > defined in somltype.h for it just as extern. And here the problem
    > may start:
    >
    > #ifndef SOMEXTERNS
    > #ifdef __GNUC__
    > #define SOMEXTERNS extern
    > #else
    > #define SOMEXTERNS extern "C"
    > #endif
    > #endif
    >
    > So it looks like a problem with GCC. I have no further idea how
    > the problem could be resolved.
    >
    > Because both, LuGbmDocumentClassData and LuGbmDocumentCClassData are
    > just structs, wouldn't it be sufficient to map the names in .def file?
    > Name mangling or linkage shouldn't have an effect here or am I wrong?


    When it comes to C++, you probably know as much or more than I do.
    As I said, I was guessing - apparently incorrectly. Lacking a real
    solution, performing name-mapping in the .def is probably the way
    to go.


    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


+ Reply to Thread