Re: Win32 DLLS - dllhelpers problem

["Kai Ruottu" <kai dot ruottu at luukku dot com>]

Paul Griffin <griffpaul4@yahoo.co.uk> write:

> The target architecture is actually an ARM7TDMI 
> 
> I've seen on Unix based systems how shared libraries
> are created with the .so extension type but as i'm
> developing on a windows machine through a cygwin host
> i need to create dlls or more to the point libraries
> of the form  libfoo.dll.a
> 
> This is essentially what dllhelpers tries to achieve
> and does so successfully on a i686-pc-cygwin version
> of gcc i have also built.

 Maybe I haven't understood the idea here... Should it
enable basically 'static' systems to use shared libs ?

> what i'm wondering is, is there some fundamental issue
> with the arm-elf target that prevents the creation of
> DLLs??? 

 The 'arm-elf' should be a system where all executables
are statically linked, ie. all the needed library functions
are linked into the executable and this executable put into
ROM with some kind of simple 'opsys'.

 Meanwhile the 'arm-linux', 'arm-epoc-pe', 'arm-wince-pe',
'arm-netbsd' and probably also the 'arm-uclinux' systems have
a mechanism where the library routines can be in 'shared' or
'dynamically linked' libraries which can be in ROM. And also
the operating system code itself can be in ROM. Maybe the
'application' programs then run from RAM or also it can be in
Flash or something... I haven't implemented these systems, but
here should be those who are...

 Anyway in their C-libraries should be routines which 'load'
the whole shared library / DLL into memory or arrange jump-
tables or something with which the application can use the
library routine. AFAIK 'newlib' doesn't provide anything for
this purpose...

> > > In file included from cdll.c:1: 
> > > cdll.h:25: warning: return type defaults to 'int' 
> > > cdll.h: In function '__declspec': 
> > > cdll.h:26: parse error before "__declspec" 

 If you build a toolchain for 'arm-pe' and the GCC-sources
support the '__declspec' with it, like with the 'arm-epoc-pe':

--------------------- clip -----------------------------------
*predefines:
-Darm -Dpe -DSYMBIAN32 -DPSISOFT32 -DGCC32 -DEPOC32 -DMARM -DEXE \
-Acpu(arm) -Amachine(arm) -D__declspec(x)=__attribute__((x))
--------------------- clip -----------------------------------

The 'arm-elf' basically doesn't support this:

--------------------- clip -----------------------------------
*predefines:
-Darm -Darm_elf -Acpu(arm) -Amachine(arm) -D__ELF__
--------------------- clip -----------------------------------

 If you simply add the '-D__declspec(x)=__attribute__((x))' into
the predefines or use it on the command line, I don't know what
happens... Neither do I know what the attributes are which the
ARM-port should support...

 In your case the 'arm-pe' target could be the one where these
things are supported, a clip from 'gcc/config/arm/pe.h' could
claim this way:

--------------------- clip -----------------------------------
/* Run-time Target Specification.  */
#undef  TARGET_VERSION
#define TARGET_VERSION fputs (" (ARM/pe)", stderr)

/* Get tree.c to declare a target-specific specialization of
   merge_decl_attributes.  */
#define TARGET_DLLIMPORT_DECL_ATTRIBUTES

/* Support the __declspec keyword by turning them into attributes.
   We currently only support: naked, dllimport, and dllexport.
   Note that the current way we do this may result in a collision 
with
   predefined attributes later on.  This can be solved by using one 
attribute,
   say __declspec__, and passing args to it.  The problem with that 
approach
   is that args are not accumulated: each new appearance would 
clobber any
   existing args.  */
#undef  SUBTARGET_CPP_SPEC
#define SUBTARGET_CPP_SPEC "-D__pe__ -
D__declspec(x)=__attribute__((x))"

--------------------- clip -----------------------------------

 Support for the 'dllimport' and 'dllexport' attributes could
be what you want... And with the 'arm-pe' it exists while with
'arm-elf' it doesn't.

 Generally I'm just a novice in this 'arm-pe' issue and would
try to learn via the stuff in :

   http://developer.intel.com/design/intelxscale

or something...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com