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.

On 09/20/08 06:04 pm, Heiko Nitzsche wrote:[color=blue]
> 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.[/color]

For EMX there is not too bad documentation. IIRC in
[url]http://hobbes.nmsu.edu/download/pub/os2/dev/emx/v0.9d/emxview.zip[/url] 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.
[color=blue]
>
> 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:[/color]

unsigned long _DLL_InitTerm (unsigned long mod_handle, unsigned long flag);
[color=blue]
> ??????
>
>
> I really need the module handle, so implementing a static object
> that gets created at load time is not sufficient.[/color]

Dave

> For EMX there is not too bad documentation. IIRC in[color=blue]
> [url]http://hobbes.nmsu.edu/download/pub/os2/dev/emx/v0.9d/emxview.zip[/url] 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.[/color]

Thanks for the pointer. I'll have a look at it.
[color=blue][color=green]
>> GCC:[/color]
>
> unsigned long _DLL_InitTerm (unsigned long mod_handle, unsigned long flag);[/color]

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

On Sun, 21 Sep 2008 01:04:45 UTC, Heiko Nitzsche <hn-expires-30dec08@arcor.de> wrote:
[color=blue]
> I really need the module handle, so implementing a static object
> that gets created at load time is not sufficient.[/color]

Is that the only reason you need the _DLL_InitTerm()? If so, use
DosQueryModFromEIP() instead.
[color=blue]
> 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.[/color]

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 | [url]http://e-vertise.com/dragtext/[/url]
___________________________________________________________________

>> I really need the module handle, so implementing a static object[color=blue][color=green]
>> that gets created at load time is not sufficient.[/color]
>
> Is that the only reason you need the _DLL_InitTerm()? If so, use
> DosQueryModFromEIP() instead.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> Which symbols? Most of the warnings are meaningless and are easy
> to resolve. Post a list of your errors - I may have some fixes.[/color]

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(lugbm.o) : error LNK2029: "_LuDocumentNewClass" : unresolved external
H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lugbm.o) : error LNK2029: "_somParentNumResolve" : unresolved external
H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lugbm.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.

[A complimentary Cc of this posting was sent to
Heiko Nitzsche
<hn-expires-30dec08@arcor.de>], who wrote in article <48d7f7cb$0$16888$9b4e6d93@newsspool1.arcor-online.net>:[color=blue][color=green][color=darkred]
> >> I really need the module handle, so implementing a static object
> >> that gets created at load time is not sufficient.[/color]
> >
> > Is that the only reason you need the _DLL_InitTerm()? If so, use
> > DosQueryModFromEIP() instead.[/color]
>
> Yeah, together with a static class instance this might work.[/color]

In C, I just use a pointer to itself.
[color=blue]
> 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.[/color]

It is in Warp3 (at least after some very early fixpak).
[color=blue]
> 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.[/color]

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;
}

On Mon, 22 Sep 2008 19:53:47 UTC, Heiko Nitzsche <hn-expires-30dec08@arcor.de> wrote:
[color=blue][color=green]
> > If so, use DosQueryModFromEIP() instead.[/color]
>
> 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.[/color]

It's been around forever. AFAICT, system exception handlers use
it to identify the module where the crash occurred.
[color=blue]
> 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.[/color]

If you already have the code in place, there's no reason to change it.
[color=blue][color=green][color=darkred]
> >> 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.[/color][/color]
>
> lugbm.xih:164: warning: `LuGbmDocumentClassData' initialized and declared
> `extern'[/color]

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.
[color=blue]
> 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(lugbm.o) : error LNK2029:
> "_LuDocumentNewClass" : unresolved external
> H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lugbm.o) : error LNK2029:
> "_somParentNumResolve" : unresolved external
> H:\GBM_SVN\rb1.61\gbmplugins\gbmlucide\lugbm.o(lugbm.o) : error LNK2029:
> "_somBuildClass" : unresolved external[/color]

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 | [url]http://e-vertise.com/dragtext/[/url]
___________________________________________________________________

>>>> There is only a minor link problem with weak SOM symbol warnings[color=blue][color=green][color=darkred]
>>>> in the Lucide GBM plugin left which I hope to find a solution for.[/color]
>> lugbm.xih:164: warning: `LuGbmDocumentClassData' initialized and declared
>> `extern'[/color]
>
> 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.[/color]

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

I did the following:

implementation
{
passthru C_xih_after = "#include <lugbmsom.hpp>";
...

and the included header file contains:

#ifdef SOMEXTERN
#undef SOMEXTERN
#endif
#define SOMEXTERN
[color=blue]
> #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.[/color]

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.

On Tue, 23 Sep 2008 01:47:54 UTC, Heiko Nitzsche <hn-expires-30dec08@arcor.de> wrote:
[color=blue]
> I could get rid of all explicit SOM related exports from the .def files :)[/color]

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 | [url]http://e-vertise.com/dragtext/[/url]
___________________________________________________________________

>> I could get rid of all explicit SOM related exports from the .def files :)[color=blue]
>
> 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.[/color]

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

>> A SOM dll is *supposed* to contain these exports in the .def file[color=blue][color=green]
>>
>> 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.[/color]
>
> OK, I'll put them back. Thanks for the pointer.[/color]

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

On Tue, 23 Sep 2008 06:58:50 UTC, Heiko Nitzsche <hn-expires-30dec08@arcor.de> wrote:
[color=blue][color=green][color=darkred]
> >> A SOM dll is *supposed* to contain these exports in the .def file
> >>
> >> EXPORTS
> >> LuGbmDocumentNewClass
> >> LuGbmDocumentClassData
> >> LuGbmDocumentCClassData[/color][/color]
>
> 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[/color]

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:
[color=blue]
> #ifdef SOMEXTERN
> #undef SOMEXTERN
> #endif
> #define SOMEXTERN[/color]

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 | [url]http://e-vertise.com/dragtext/[/url]
___________________________________________________________________

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.

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

You might want to ask on the libc users list. Perhaps Knut remembers why
he did things like this and the best way around...
[color=blue]
>
> 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.[/color]

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

On Wed, 24 Sep 2008 01:14:37 UTC, Heiko Nitzsche <hn-expires-30dec08@arcor.de> wrote:
[color=blue]
> 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?[/color]

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 | [url]http://e-vertise.com/dragtext/[/url]
___________________________________________________________________