RE: dll, java, gcc, cygwin

RE: dll, java, gcc, cygwin

[Philip A. Larson]

Paul, and others. 

I have the following problems when running Cygwin / Qub perl on my Windows 95 machine. Any ideas?

1.)  The BASH shell, indeed the whole bloody computer locks up if you try to run some DOS commands or programs.  The Cygwin FAQ talks about lock-ups with Ctrl-C and downloading a USB patch from OSR2, but I don't thinks it applies.
2.)  Same old problem with getting files to accept permission or ownership changes. Probably because their is no passwd file and when I run mkpasswd it can't find an export function in an API dll. I get affirmative reports when using the -v verbose flag. You have some control over the owner write property if you set the archive, and read only attributes in DOS mode.  Any directory or file ending in .exe, or .com, or .bat, or .pif gets a "x" in the owners permissions.
3.)  The "make test" functions don't work in the install directory on the Storable module I successfully compiled. They work fine if you go ahead and install it and then re-run the tests. 
4.)   "ansidecl.h" is missing from both Cygwin and Qub/perl.  I got one from an old egcs1-1b tar file I had.

Many Thanks,

Phil Larson




-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[John A. Turner]

"Philip A. Larson" wrote:
> 
> Paul, and others.
> 
> I have the following problems when running Cygwin / Qub perl on my Windows 95 machine. Any ideas?
> 
> 1.)  The BASH shell, indeed the whole bloody computer locks up if you try to run some DOS commands or programs.  The Cygwin FAQ talks about lock-ups with Ctrl-C and downloading a USB patch from OSR2, but I don't thinks it applies.

Don't be so sure.  I had consistent, repeatable lockups under 95 until I
applied the USB patch.

Thankfully, I no longer use that godforsaken OS with Cygwin.  Now I only
use Cygwin on NT (which is slightly less godforsaken).

--
John A. Turner
Blue Sky | VIFX    - http://www.blueskystudios.com/
Los Alamos Nat Lab - http://www.lanl.gov/home/turner/
Personal           - http://john.turner.org/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Earnie Boyd]

Have you tried using the libmmalloc.a library that comes with the
cygwin package for your malloc and friends routines?  Note: that there
are two m's and is a Mapped Memory Allocation package.  This has
seemed to fix various other porters problems when I've suggested it.


---Glen Fullmer-EGF002 <Glen_Fullmer-EGF002@email.mot.com> wrote:
>
> Hi Mumit,
> 
> >>>>> "MK" == Mumit Khan <khan@xraylith.wisc.edu> writes:
> 
>    MK> Tried something similar, and sure enough, it crashed and
burned.
>    MK> getenv() probably calls something that calls malloc. If
malloc fails,
>    MK> the system is pretty much useless.
> 
> Yep, also just:
> 
>      char *mstr;
>      mstr = malloc(100);
> 
> fails, in the helloworld example.
>      
>    MK> Of course, everything seems to work when using mingw, but
then you
>    MK> lose the POSIX layer.
> 
> Yeah, we wouldn't want to do that. ;-)
> 
>    MK> problem must be due to some (bad) interaction of MSVC runtime
loaded
>    MK> by Java and Cygwin runtime loaded by the JNI dll.
> 
> Ok, but I don't understand.  So you are saying that Java might be
using a
> runtime library that is not compatible with the DLL library?
> 
> Thanks, 
> Glen
> -- 
> Glen Fullmer,(847)538-3082, Mail: <gfullmer@ccrl.mot.com>,
>  			    Web:  < http://www.enteract.com/~gfullmer >
>
**************************************************************************
> *  "For a successful technology, reality must take precedence       
    *
> *   over public relations, for Nature cannot be fooled." - R. P.
Feynman *
>
**************************************************************************
> -
> For help on using this list (especially unsubscribing), send a
message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
> 

==
-                  \\||//
-------------o0O0--Earnie--0O0o--------------
--          earnie_boyd@yahoo.com          --
-- http://www.freeyellow.com/members5/gw32 --
----------------ooo0O--O0ooo-----------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Mumit Khan]

Earnie Boyd <earnie_boyd@yahoo.com> writes:
> 
> Have you tried using the libmmalloc.a library that comes with the
> cygwin package for your malloc and friends routines?  Note: that there
> are two m's and is a Mapped Memory Allocation package.  This has
> seemed to fix various other porters problems when I've suggested it.

I tend to shudder everytime someone recommends a different malloc
package to fix bugs in code; more often than not, it just hides the
bug waiting to bite on another platform. There are pretty reliable
ways to debug memory allocation problems (eg., we use Purify on all
our supported platforms).

I don't remember if I already responded to Glenn's message or not 
(or if I copied the list or not), so here's quick recap to avoid 
further confusion and speculation.

  - cygwin app loading cygwin dll ................ OK
  - cygwin app loading "native" dll .............. OK if you do it right
  - "native" app loading cygwin dll .............. NOT OK (bug!)

Here I'm using "native" for msvc or mingw compiled apps. Since Java is
a "native" app, you just can't load cygwin JNI dll until this bug is
fixed. There is also an issue of threading with Java when loading a
cygwin JNI DLL, and I have yet to look in that direction.

I've tracked down the problem, but have no idea what the solution is.
Basically, the DLL startup is not initializing Cygwin properly (yes,
I did take all the necessary steps for cygwin), and pretty much 
everything that requires impure_ptr will crash, which includes all the
stdio, memory allocation, etc in newlib.

I've submitted a test case to cygwin32 developers and hopefully someone
will come forward and figure it out. It's a bit beyond my expertise ...

It's not a memory allocation problem per se, but a much larger one.

Regards,
Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Glen Fullmer-EGF002]

>>>>> "EB" == Earnie Boyd <earnie_boyd@yahoo.com> writes:

   EB> Have you tried using the libmmalloc.a library that comes with the
   EB> cygwin package for your malloc and friends routines?  Note: that
   EB> there are two m's and is a Mapped Memory Allocation package.  This
   EB> has seemed to fix various other porters problems when I've suggested
   EB> it.
   EB> ---Glen Fullmer-EGF002 <Glen_Fullmer-EGF002@email.mot.com> wrote:
   >> char *mstr;
   >> mstr = malloc(100);
   >> 

Yep, still crashes.  In fact extracting mm.o from the library and including
in the object list crashes also.

-- 
Glen Fullmer,(847)538-3082		 Mail: <gfullmer@ccrl.mot.com>,
**************************************************************************
*  "For a successful technology, reality must take precedence            *
*   over public relations, for Nature cannot be fooled." - R. P. Feynman *
**************************************************************************
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Glen Fullmer-EGF002]

Hi Mumit,

>>>>> "MK" == Mumit Khan <khan@xraylith.wisc.edu> writes:

   MK> Tried something similar, and sure enough, it crashed and burned.
   MK> getenv() probably calls something that calls malloc. If malloc fails,
   MK> the system is pretty much useless.

Yep, also just:

     char *mstr;
     mstr = malloc(100);

fails, in the helloworld example.
     
   MK> Of course, everything seems to work when using mingw, but then you
   MK> lose the POSIX layer.

Yeah, we wouldn't want to do that. ;-)

   MK> problem must be due to some (bad) interaction of MSVC runtime loaded
   MK> by Java and Cygwin runtime loaded by the JNI dll.

Ok, but I don't understand.  So you are saying that Java might be using a
runtime library that is not compatible with the DLL library?

Thanks, 
Glen
-- 
Glen Fullmer,(847)538-3082, Mail: <gfullmer@ccrl.mot.com>,
 			    Web:  < http://www.enteract.com/~gfullmer >
**************************************************************************
*  "For a successful technology, reality must take precedence            *
*   over public relations, for Nature cannot be fooled." - R. P. Feynman *
**************************************************************************
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: dll, java, gcc, cygwin

[Philip A. Larson]

Hey! That worked.

Sometimes it just takes a little push.

Thanks,

Phil

----------
From:  John A. Turner[SMTP:John.Turner@pobox.com]
Sent:  Saturday, October 24, 1998 1:29 PM
To:  gnu-win32@cygnus.com
Subject:  Re: dll, java, gcc, cygwin

"Philip A. Larson" wrote:
> 
> Paul, and others.
> 
> I have the following problems when running Cygwin / Qub perl on my Windows 95 machine. Any ideas?
> 
> 1.)  The BASH shell, indeed the whole bloody computer locks up if you try to run some DOS commands or programs.  The Cygwin FAQ talks about lock-ups with Ctrl-C and downloading a USB patch from OSR2, but I don't thinks it applies.

Don't be so sure.  I had consistent, repeatable lockups under 95 until I
applied the USB patch.

Thankfully, I no longer use that godforsaken OS with Cygwin.  Now I only
use Cygwin on NT (which is slightly less godforsaken).

--
John A. Turner
Blue Sky | VIFX    - http://www.blueskystudios.com/
Los Alamos Nat Lab - http://www.lanl.gov/home/turner/
Personal           - http://john.turner.org/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Earnie Boyd]

---Mumit Khan <khan@xraylith.wisc.edu> wrote:
>
> On Thu, 22 Oct 1998, Andrew Mickish wrote:
> 
> > It might be related to name mangling.  Try adding .def aliases in
your larger
> > example.  I have to supply aliases in a .def file like the
following for every native
> > method I export from the DLL:
> > 
> >      EXPORTS
> >     
Java_HelloWorld_displayHelloWorld=Java_HelloWorld_displayHelloWorld@8
> >      dll_entry@12
> > 
> 
> Here's a proposal: how about I add a --add-stdcall-alias to dlltool
which
> essentially produce the following:
> 
>       EXPORTS
>      
Java_HelloWorld_displayHelloWorld=Java_HelloWorld_displayHelloWorld@8
>       Java_HelloWorld_displayHelloWorld@8
> 
> When creating .def file using ``dlltool --output-def''. Would this
solve 
> the problem? Note that I'm keeping the original symbol as well, but
we 
> could always get rid of that too.
> 

Please, group them together for ease of spliting the file, i.e.:

ThisFunc=ThisFunc@8
ThatFunc=ThatFunc@8
ThisFunc@8
ThatFunc@8


==
-                  \\||//
-------------o0O0--Earnie--0O0o--------------
--          earnie_boyd@yahoo.com          --
-- http://www.freeyellow.com/members5/gw32 --
----------------ooo0O--O0ooo-----------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Mumit Khan]

Earnie Boyd <earnie_boyd@yahoo.com> writes:
> Please, group them together for ease of spliting the file, i.e.:
> 
> ThisFunc=ThisFunc@8
> ThatFunc=ThatFunc@8
> ThisFunc@8
> ThatFunc@8
> 

Earnie,

A good suggestion, but unfortunately that's going to be messy since all 
the exports are sorted, and I don't really want to add special logic just 
for this. Easiest way to split is to just re-create without the new
--add-stdcall-alias option (or use sed/perl/awk/what-not).

How about I add a special comment to each auto-added alias, such as
``added by --add-stdcall-alias'' that you can use to delete those lines?

There's always an easy way out -- use sed or perl. For example, to turn 
foo.def:

  EXPORTS
  	foo@1 @ 1;		add alias to this
	blah @ 2;		don't mess with this one

into foo2.def:

  EXPORTS
  	foo = foo@1 @ 1;	add alias to this
	blah @ 2;		don't mess with this one

I would use the following:
  
  $ < foo.def > foo2.def \
  sed -e 's,\([A-Za-z$:\-\_?][A-Za-z0-9/$:\-\_?]*\)\(@[0-9]*\),\1 = \1\2,'

But, since regexp seem to give people a stomach ache, I've added the
--add-stdcall-alias (and hopefully soon I'll upload a new version of
dllhelpers package that includes this dlltool and an enhanced dllwrap 
that adds a few useful features).

Note that the regexp above is almost the same as the one used in binutils
to recognize IDs, except for the missing '@' in \1.

Regards,
Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

dll, java, gcc, cygwin

[Glen Fullmer-EGF002]

Hi,

I thought others might be interested in this letter I sent to Mumit:
-----
I tried using your dllwrap tool and method to create the JNI HelloWorld
example and it failed as it couldn't find the native routine in the library,
whereas Andrew Mickish's method:
	
	http://www.andrew.cmu.edu/~am2q/HelloWorld.zip 

worked fine for the HelloWorld code. Looking at the code I can't see any
glaring differences.  His makefile uses the loader/dlltool/loader/dlltool
method.  I tried using Andrew's example on a larger piece of code and it
behaves the same as yours, i.e. the library loads but it can't find the
routines within the library.  Perhaps his can only load one routine?  ;-)
Any hints?

My environment is:

   Windows/NT on a dual processor pentium.  
   gcc -v = egcs-2.91.57 19980901 (egcs-1.1 release) (cygwin - B19)
   binutils (2.7-B19)
   dllhelpers-0.2.1

I had to set DLL_LDFLAGS = -Wl,-e,_dll_entry@12 to avoid errors.

Your dllwrap method failed with:

============================Makefile================================

.SUFFIXES:	.java
.SUFFIXES:	.class

DLL_OBJS = HelloWorldImp.o 

DLL_NAME = hello.dll
DLL_EXP_DEF = hello.def
DLL_EXP_LIB = libhello.a
DLLWRAP = dllwrap
DLLTOOL = dlltool

JAVA_HOME=/jdk1.1.6

# Java Files
JSRCS = HelloWorld.java Main.java

JLIBBIN = HelloWorldImp.o

JOBS=$(JSRCS:.java=.class)

DLLWRAP_FLAGS = --driver-name $(CC) --def $(DLL_EXP_DEF)
DLL_CFLAGS = -DBUILDING_DLL=1

# The default entry point defined by dllwrap is DllMain defined in 
# dllinit.c. You can override that here by specifying it in DLL_LDFLAGS.
# (eg., -Wl,-e,_MyDllMain@12 -- note the leading underscore and the
# trailing @12).
DLL_LDFLAGS = -Wl,-e,_dll_entry@12

all:	$(DLL_NAME) $(JOBS) $(JLIBBIN)

$(DLL_NAME):	$(DLL_OBJS) $(DLL_EXP_DEF)
	$(DLLWRAP) $(DLLWRAP_FLAGS) -o $(DLL_NAME) \
	   $(DLL_OBJS) $(DLL_LDFLAGS) $(DLL_LDLIBS)

$(DLL_EXP_LIB): $(DLL_EXP_DEF)
	$(DLLTOOL) --dllname $(DLL_NAME) --def $(DLL_EXP_DEF) \
		--oubput-lib $(DLL_EXP_LIB)
$(DLL_EXP_DEF): $(DLL_OBJS)
	$(DLLTOOL) --export-all --output-def $@ $(DLL_OBJS)

HelloWorldImp.o: HelloWorldImp.c HelloWorld.h
	gcc -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/win32 -c HelloWorldImp.c

.java.class:
	$(JAVA_HOME)/bin/javac $*.java

HelloWorld.h: HelloWorld.class
	$(JAVA_HOME)/bin/javah HelloWorld

clean:
	rm -f *.class *.o core hello.dll* 

==============================HelloWorld.java============================
class HelloWorld {
  public native void displayHelloWorld();
  
  static {
    System.loadLibrary("hello");
  }
}

==============================HelloWorldImp.c============================
/* following for PC port */
#define __int64 long  

#include <jni.h>
#include "HelloWorld.h"
#include <stdio.h>

JNIEXPORT void JNICALL 
Java_HelloWorld_displayHelloWorld(JNIEnv *env, jobject obj) 
{
  printf("Hello world!\n");
  return;
}
==============================Output=====================================
/jdk1.1.6/bin/javac HelloWorld.java
/jdk1.1.6/bin/javah HelloWorld
gcc -I/jdk1.1.6/include -I/jdk1.1.6/include/win32 -c HelloWorldImp.c
dlltool --export-all --output-def hello.def HelloWorldImp.o 
dllwrap --driver-name gcc --def hello.def -o hello.dll \
   HelloWorldImp.o  -Wl,-e,_dll_entry@12 
/jdk1.1.6/bin/javac Main.java

/jdk1.1.6/bin/java Main
java.lang.UnsatisfiedLinkError: displayHelloWorld
				at Main.main(Main.java:3)

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

Am I missing something here? (besides my sanity! ;-)

Thanks,

Glen
-- 
Glen Fullmer,(847)538-3082, Mail: <gfullmer@ccrl.mot.com>,
*******************************************************************************
*  "For a successful technology, reality must take precedence                 *
*   over public relations, for Nature cannot be fooled." - Richard P. Feynman *
*******************************************************************************

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Andrew Mickish]

It might be related to name mangling.  Try adding .def aliases in your larger
example.  I have to supply aliases in a .def file like the following for every native
method I export from the DLL:

     EXPORTS
     Java_HelloWorld_displayHelloWorld=Java_HelloWorld_displayHelloWorld@8
     dll_entry@12

The @8, @12, etc is four * the number of parameters in the function definition.  This
has something to do with telling the compiler how it should pop parameters off the
stack when returning from a function.  All JNI methods have at least two parameters --
an object representing the Java environment and the object whose method is being
invoked.

--Andrew Mickish


Glen Fullmer-EGF002 wrote:

> Hi,
>
> I thought others might be interested in this letter I sent to Mumit:
> -----
> I tried using your dllwrap tool and method to create the JNI HelloWorld
> example and it failed as it couldn't find the native routine in the library,
> whereas Andrew Mickish's method:
>
>         http://www.andrew.cmu.edu/~am2q/HelloWorld.zip
>
> worked fine for the HelloWorld code. Looking at the code I can't see any
> glaring differences.  His makefile uses the loader/dlltool/loader/dlltool
> method.  I tried using Andrew's example on a larger piece of code and it
> behaves the same as yours, i.e. the library loads but it can't find the
> routines within the library.  Perhaps his can only load one routine?  ;-)
> Any hints?
>
> My environment is:
>
>    Windows/NT on a dual processor pentium.
>    gcc -v = egcs-2.91.57 19980901 (egcs-1.1 release) (cygwin - B19)
>    binutils (2.7-B19)
>    dllhelpers-0.2.1
>
> I had to set DLL_LDFLAGS = -Wl,-e,_dll_entry@12 to avoid errors.
>
> Your dllwrap method failed with:
>
> ============================Makefile================================
>
> .SUFFIXES:      .java
> .SUFFIXES:      .class
>
> DLL_OBJS = HelloWorldImp.o
>
> DLL_NAME = hello.dll
> DLL_EXP_DEF = hello.def
> DLL_EXP_LIB = libhello.a
> DLLWRAP = dllwrap
> DLLTOOL = dlltool
>
> JAVA_HOME=/jdk1.1.6
>
> # Java Files
> JSRCS = HelloWorld.java Main.java
>
> JLIBBIN = HelloWorldImp.o
>
> JOBS=$(JSRCS:.java=.class)
>
> DLLWRAP_FLAGS = --driver-name $(CC) --def $(DLL_EXP_DEF)
> DLL_CFLAGS = -DBUILDING_DLL=1
>
> # The default entry point defined by dllwrap is DllMain defined in
> # dllinit.c. You can override that here by specifying it in DLL_LDFLAGS.
> # (eg., -Wl,-e,_MyDllMain@12 -- note the leading underscore and the
> # trailing @12).
> DLL_LDFLAGS = -Wl,-e,_dll_entry@12
>
> all:    $(DLL_NAME) $(JOBS) $(JLIBBIN)
>
> $(DLL_NAME):    $(DLL_OBJS) $(DLL_EXP_DEF)
>         $(DLLWRAP) $(DLLWRAP_FLAGS) -o $(DLL_NAME) \
>            $(DLL_OBJS) $(DLL_LDFLAGS) $(DLL_LDLIBS)
>
> $(DLL_EXP_LIB): $(DLL_EXP_DEF)
>         $(DLLTOOL) --dllname $(DLL_NAME) --def $(DLL_EXP_DEF) \
>                 --oubput-lib $(DLL_EXP_LIB)
> $(DLL_EXP_DEF): $(DLL_OBJS)
>         $(DLLTOOL) --export-all --output-def $@ $(DLL_OBJS)
>
> HelloWorldImp.o: HelloWorldImp.c HelloWorld.h
>         gcc -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/win32 -c HelloWorldImp.c
>
> .java.class:
>         $(JAVA_HOME)/bin/javac $*.java
>
> HelloWorld.h: HelloWorld.class
>         $(JAVA_HOME)/bin/javah HelloWorld
>
> clean:
>         rm -f *.class *.o core hello.dll*
>
> ==============================HelloWorld.java============================
> class HelloWorld {
>   public native void displayHelloWorld();
>
>   static {
>     System.loadLibrary("hello");
>   }
> }
>
> ==============================HelloWorldImp.c============================
> /* following for PC port */
> #define __int64 long
>
> #include <jni.h>
> #include "HelloWorld.h"
> #include <stdio.h>
>
> JNIEXPORT void JNICALL
> Java_HelloWorld_displayHelloWorld(JNIEnv *env, jobject obj)
> {
>   printf("Hello world!\n");
>   return;
> }
> ==============================Output=====================================
> /jdk1.1.6/bin/javac HelloWorld.java
> /jdk1.1.6/bin/javah HelloWorld
> gcc -I/jdk1.1.6/include -I/jdk1.1.6/include/win32 -c HelloWorldImp.c
> dlltool --export-all --output-def hello.def HelloWorldImp.o
> dllwrap --driver-name gcc --def hello.def -o hello.dll \
>    HelloWorldImp.o  -Wl,-e,_dll_entry@12
> /jdk1.1.6/bin/javac Main.java
>
> /jdk1.1.6/bin/java Main
> java.lang.UnsatisfiedLinkError: displayHelloWorld
>                                 at Main.main(Main.java:3)
>
> =========================================================================
>
> Am I missing something here? (besides my sanity! ;-)
>
> Thanks,
>
> Glen
> --
> Glen Fullmer,(847)538-3082, Mail: <gfullmer@ccrl.mot.com>,
> *******************************************************************************
> *  "For a successful technology, reality must take precedence                 *
> *   over public relations, for Nature cannot be fooled." - Richard P. Feynman *
> *******************************************************************************
>
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Mumit Khan]

On Thu, 22 Oct 1998, Andrew Mickish wrote:

> It might be related to name mangling.  Try adding .def aliases in your larger
> example.  I have to supply aliases in a .def file like the following for every native
> method I export from the DLL:
> 
>      EXPORTS
>      Java_HelloWorld_displayHelloWorld=Java_HelloWorld_displayHelloWorld@8
>      dll_entry@12
> 

Here's a proposal: how about I add a --add-stdcall-alias to dlltool which
essentially produce the following:

      EXPORTS
      Java_HelloWorld_displayHelloWorld=Java_HelloWorld_displayHelloWorld@8
      Java_HelloWorld_displayHelloWorld@8

When creating .def file using ``dlltool --output-def''. Would this solve 
the problem? Note that I'm keeping the original symbol as well, but we 
could always get rid of that too.

Making DLLs then look like the following:
  
  dlltool --output-def my.def --add-stdcall-alias [ ... ] *.o
  dllwrap -o my.dll --def my.def [ .... ]*.o

btw, you should *never* export DLL entry points (unless you really know
what you're doing of course).

Regards,
Mumit


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Mumit Khan]

On Wed, 21 Oct 1998, Glen Fullmer-EGF002 wrote:

> I thought others might be interested in this letter I sent to Mumit:

(thanks for sending it to gnu-win32 as well; it's more productive than
sending it to just me, and that's I ask folks to send it to the list
and perhaps copy me if they so wish.)

> I tried using your dllwrap tool and method to create the JNI HelloWorld
> example and it failed as it couldn't find the native routine in the library,
> whereas Andrew Mickish's method:
> 	
> 	http://www.andrew.cmu.edu/~am2q/HelloWorld.zip 
> 
> worked fine for the HelloWorld code. Looking at the code I can't see any
> glaring differences.  His makefile uses the loader/dlltool/loader/dlltool
> method.  I tried using Andrew's example on a larger piece of code and it
> behaves the same as yours, i.e. the library loads but it can't find the
> routines within the library.  Perhaps his can only load one routine?  ;-)
> Any hints?

Whenver loading fails, and you know that it's there, it's typically a
question of calling the correct "name". For my applications, my load
routines check for "foo" and "_foo" when asked to load "foo" to avoid
MSVC vs GCC symbol naming issues.

Are you creating .def files yourself? Are you checking to make sure
that the decoration is correct (stdcall attribute adds those pesky
@[num] at the end of symbols?

Check the export table/ordinals in the DLL for the symbol definitions.
If you have MSVC, you can use 'dumpbin /exports'; otherwise use
`objdump -p'.

> I had to set DLL_LDFLAGS = -Wl,-e,_dll_entry@12 to avoid errors.

The DLL entry point is of course a function of that particular
application.  Most are content with the default, but some need
special ones. 

Regards,
Mumit


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dll, java, gcc, cygwin

[Glen Fullmer-EGF002]

Hello all,

>>>>> "MK" == Mumit Khan <khan@xraylith.wisc.edu> writes:

   MK> Whenver loading fails, and you know that it's there, it's typically a
   MK> question of calling the correct "name". For my applications, my load
   MK> routines check for "foo" and "_foo" when asked to load "foo" to avoid
   MK> MSVC vs GCC symbol naming issues.

I notice the difference between the ones that load and those that don't.  

Andrew Mickish's .def has entries in name=name@nn form while yours has them
in name@nn form. When I changed yours to the former and changed the printf
to Andrew's jprintf it works too.  It would be very nice if dlltool was
documented. I keep trying to guess what the syntax means!

Andrew mentions another gotcha. He says that printf will not work because
stdout is not accessible from cygwin's gcc/g++?  Is that correct?  It
definitely crashes with a printf in there on the NT box, but on the Sun
and HP we use gcc/g++ also and have no problem executing printf in our JNI
code. On those machines there is a problem calling printf in routines that
the JNI calls, but in the JNI code itself, it seems to work fine.  What is
the difference?  I noticed your code doesn't use jprintf like Andrew's.
How come?

   MK> Are you creating .def files yourself? Are you checking to make sure
   MK> that the decoration is correct (stdcall attribute adds those pesky
   MK> @[num] at the end of symbols?

No, I let your dllwrap do it.  It creates the name@nn form, and then I go
back and change it to the name=name@nn form by hand and run the stuff that
dllwrap would have done after the .def is created.

Thanks,
Glen.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".