Re: Windows DLLs from Unix with minimum effort

[Roumen Petrov]

Jason Curl wrote:
> Brian Dessent wrote:
> > Jason Curl wrote:
> >
> >  
> > >  ./configure CC="gcc -mno-cygwin" LDFLAGS="-Wl,--kill-at" 
> > > --target=i586-pc-mingw32 --disable-static
> > > on Cygwin to generate the Windows DLL
> > >     
> >
> > Target is not the right thing to use here.  Target only has meaning in
> > the context of building tools that themselves generate code, such as
> > compilers, linkers, assemblers, etc.  If you want to simply indicate
> > that you are cross-compiling a library for a host different than the
> > current one then you use --host.  Also, if you're going to use Cygwin as
> > a "Fake mingw" then you probably also should use --build=mingw as well.
> >   
> Thanks - all of my initial problems. My test code now compiles and 
> links with the DLL. However, when I move the test program out into 
> another folder and copy the DLL into the Windows System path, it 
> doesn't execute. I haven't figured out how to run it without the 
> "libtool" wrapper. When I observe the dependencies using Microsoft 
> tools, I see there are none other than my library and MS libraries 
> (e.g. Cygwin is not there).
>
> The library works correctly when I use say, Visual Basic 6.

Please, could you prepare sample test case.
I cannot reproduce described issue.


> > > I have also another subdirectory that tests the library but I can't 
> > > link to it using mingw. First it doesn't recognise that the name was 
> > > simplified (it looks for address@hidden for example instead of 
> > > _my_func/my_func).
> > >     
> >
> > You need to understand that the --kill-at is a linker option.  It cannot
> > change behavior of the compiler, and when gcc is told to use the stdcall
> > calling convention for a function, it includes the normal stdcall
> > decorations on the symbol.  There is no way to change this AFAIK, unless
> > you use __attribute__((alias)) or something.
> >   
> Ooh sounds horrible.
> > So if you want to use these symbols without the stdcall decoration, then
> > you have to get the linker to jump throuh hoops.  --kill-at removes them
> > from names that are exported, but that still doesn't change the fact
> > that the compiler emits calls to the decorated names.  For that you will
> > have to use --enable-stdcall-fixup, which will link calls to address@hidden to
> > _foo if there is no address@hidden found anywhere.  Or, you could create an
> > import library and link with that.
> >
> > But instead of all of that I think I would just simply use
> > --add-stdcall-alias.  This should result in both a decorated and
> > undecorated alias of each symbol being exported, so you don't have to
> > try to pretend that gcc isn't emitting calls to decorated names when it
> > really is.
> >   
> I can probably live with that solution, I might look how to use 
> export/import library definitions as it would also mean defining 
> precisely the ordinals in the Windows DLLs. I'll take a deeper look at 
> Erik's suggestion, it looks simple enough except I'm not entirely 
> happy with the DEF file generation he uses.

You could pass "def"  file to the linker as example:
http://svn.gnome.org/viewvc/xmlsec/trunk/configure.in?r1=982&r2=983

Roumen