RE: Where can I get Cygwin 20.1b?

RE: Where can I get Cygwin 20.1b?

[Michael Nelson]

> > Use of dllimport is unnecessary, just link with the import lib.
> 
> Really?  Is that true of _all_ Windows compilers?

GCC and VC at least, those are the only two Win32 compilers I've used to a
significant extent.

> Just your externally visible symbols are exposed, not the 
> "guts" .  They are
> all exposed and accessible under Windows too, regardless of what you
> export!  Don't be fooled into thinking that just because you 
> don't put it in
> your export list that it is not exposed. LoadLibrary() and 
> GetProcAddress()
> work just fine regardless of whether or not the symbol was 
> exported to an
> import library!  
> So I hope your company doesn't rely on its 
> DLLs "guts" not
> being exposed simply because you don't put an entry in your 
> .def file...

With VC, if it isn't in a .DEF file or dllexport'd, it isn't accessible via
GPA().

I just double checked all of this, and it seems GCC is a bit more tricky. If
you have 0 symbols marked with dllexport all public symbols get exported. If
you have >0 symbols marked with dllexport, only they get exported.

I think this is where the mixup is.

What I miss on UNIX is the latter feature, the ability it to only export
exactly these symbols. 

-mike

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Where can I get Cygwin 20.1b?

[Carl Thompson]

Michael Nelson wrote:
> 
> With VC, if it isn't in a .DEF file or dllexport'd, it isn't
> accessible via GPA().
> 
> I just double checked all of this, and it seems GCC is a bit more
> tricky. If you have 0 symbols marked with dllexport all public symbols
> get exported. If you have >0 symbols marked with dllexport, only they
> get exported.
> 
> I think this is where the mixup is.
> 
> What I miss on UNIX is the latter feature, the ability it to only
> export exactly these symbols.

OK, I will grudgingly concede that Windows might be better in that one
little respect, then... ;-)

> -mike

Carl Thompson

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Where can I get Cygwin 20.1b?

[Larry Hall (RFK Partners, Inc)]

At 09:50 AM 6/16/2000, Phil Edwards wrote:

>Carl Thompson <cet@carlthompson.net>:
> > Michael Nelson wrote:
> > > 
> > > I just double checked all of this, and it seems GCC is a bit more
> > > tricky. If you have 0 symbols marked with dllexport all public symbols
> > > get exported. If you have >0 symbols marked with dllexport, only they
> > > get exported.
> > > 
> > > I think this is where the mixup is.
> > > 
> > > What I miss on UNIX is the latter feature, the ability it to only
> > > export exactly these symbols.
> >
> > OK, I will grudgingly concede that Windows might be better in that one
> > little respect, then... ;-)
>
>I won't.  :-)  This feature is available on "Unix" but it isn't standardized.
>It depends heavily (AFAICT) on the platform and the linker.


And MS O/S - compiler - linker features in this area aren't standardized 
either so that's really not a mark against the UNIXes that do handle this 
in their own way!;-)





Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                        (508) 560-1285 - cell phone



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Where can I get Cygwin 20.1b?

[Phil Edwards]

Carl Thompson <cet@carlthompson.net>:
> Michael Nelson wrote:
> > 
> > I just double checked all of this, and it seems GCC is a bit more
> > tricky. If you have 0 symbols marked with dllexport all public symbols
> > get exported. If you have >0 symbols marked with dllexport, only they
> > get exported.
> > 
> > I think this is where the mixup is.
> > 
> > What I miss on UNIX is the latter feature, the ability it to only
> > export exactly these symbols.
>
> OK, I will grudgingly concede that Windows might be better in that one
> little respect, then... ;-)

I won't.  :-)  This feature is available on "Unix" but it isn't standardized.
It depends heavily (AFAICT) on the platform and the linker.

Luck++;
Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Where can I get Cygwin 20.1b?

[Carl Thompson]

Michael Nelson wrote:
> 
> > That's a complicated question.  Essentially, the MS engineers
> > were on crack when they designed Windows DLLs.
> >
> > [long discussion]
> 
> Use of dllimport is unnecessary, just link with the import lib.

Really?  Is that true of _all_ Windows compilers?

> > PPS: I've heard you can do the same thing using separate
> > ".DEF" files, but I don't know about that.
> 
> This is what most people do.

That doesn't make it better.

> > PPPS: None of this is necessary with reasonable operating
> > systems, such as Unix or Linux.  The compiler and linker 
> > automatically export and import all externally visible symbols
> > when building or using DLLs (shared libraries).  You don't
> > even need a separate import library.
> 
> The drawback with "reasonable" operating systems is that all of your
> internal guts are exposed to the world. For some that is a
> disadvantage.

Just your externally visible symbols are exposed, not the "guts" .  They are
all exposed and accessible under Windows too, regardless of what you
export!  Don't be fooled into thinking that just because you don't put it in
your export list that it is not exposed.  LoadLibrary() and GetProcAddress()
work just fine regardless of whether or not the symbol was exported to an
import library!  So I hope your company doesn't rely on its DLLs "guts" not
being exposed simply because you don't put an entry in your .def file...

In short, Windows DLLs afford _no_ benefits over Unix shared libraries but
are much more difficult to build, use and maintain.  So, yes, I do believe
that the Unix method is "reasonable" and the Windows method is not.

> -mike

Hope this clears things up for you,
Carl Thompson

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Where can I get Cygwin 20.1b?

[Michael Nelson]

> That's a complicated question.  Essentially, the MS engineers 
> were on crack
> when they designed Windows DLLs. 
> 
> [long discussion]

Use of dllimport is unnecessary, just link with the import lib.

> PPS: I've heard you can do the same thing using separate 
> ".DEF" files, 
>      but I don't know about that.

This is what most people do. 

> PPPS: None of this is necessary with reasonable operating 
> systems, such
>       as Unix or Linux.  The compiler and linker automatically export
>       and import all externally visible symbols when building or using
>       DLLs (shared libraries).  You don't even need a separate import
>       library.

The drawback with "reasonable" operating systems is that all of your
internal guts are exposed to the world. For some that is a disadvantage. 

-mike

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Where can I get Cygwin 20.1b?

[Carl Thompson]

Bradley Smith wrote:
> 
> Thank you very much for responding to my question.
> 
> Could you please tell me where I might read more on
> __declspec(dllexport) and __declspec(dllimport)
> 
> I do not understand how to use these....

That's a complicated question.  Essentially, the MS engineers were on crack
when they designed Windows DLLs.  When compiling code to become a DLL, you
must explicitly tell the compiler which symbols(1) will be exported(2) from
the DLL in the declarations(3) of the symbols.  When compiling code that
will use a DLL, you must explicitly tell the compiler which symbols will be
imported from DLLs as opposed to statically linked into your program.  At
first this doesn't sound so bad, but essentially it means you need three
different versions of all of your declarations for:
   1. compiling code to become the DLL
   2. compiling code to use the DLL
   3. compiling code that will be statically linked

Consider the case of function "foo()" defined in "foo.c" that will be used
in the "main()" of a program "bar.exe" that is defined in "bar.c" . If foo()
is statically linked into bar.exe, your files might look like this:

   --- foo.c ---
   /* declaration (AKA prototype) of foo(), usually found in .h file */
   int foo();

   /* definition of foo() */
   int foo() { return 1; }
   -------------

Compile foo.c:
   gcc -c foo.c -o foo.o

   --- bar.c ---
   /* declaration (AKA prototype) of foo(), usually found in .h file */
   int foo();

   int main() { return foo(); }
   --------------

Compile bar.c and link foo.o into bar.exe statically:

   gcc -c bar.c -o bar.o
   gcc foo.o bar.o -o bar.exe

However, if foo() should go into a DLL, your files need to look like this:

   --- foo.c ---
   /* declaration (AKA prototype) of foo(), usually found in .h file */
   __declspec(dllexport) int foo(); /* exporting foo() from this DLL */

   /* definition of foo() */
   int foo() { return 1; }
   -------------

Make a DLL from foo.c:

   gcc -c foo.c -o foo.o
   gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o

This will create the DLL (foo.dll) and the import library for the DLL
(libfoo.import.a).

   --- bar.c ---
   /* declaration (AKA prototype) of foo(), usually found in .h file */
   __declspec(dllimport) int foo(); /* importing foo() from DLL */

   int main() { return foo(); }
   --------------

Compile and link bar.exe to use foo.dll (via its import library):

   gcc -c bar.c -o bar.o
   gcc bar.o libfoo.import.a -o bar.exe

bar.exe now uses foo.dll.

So we have three different possible declarations of the function foo():
   1. int foo(); /* static linking */
   2. __declspec(dllexport) int foo(); /* making DLL with foo() in it */
   3. __declspec(dllimport) int foo(); /* importing foo() from DLL */

Which one we use depends on how we are using foo().  The real problem is
that most people don't want to deal with three sets of declarations but want
to just have one header file which is used in all cases.  To solve this you
could do something like this:

   --- foo.h ---
   #if defined(MAKEDLL)
   #  define INTERFACE __declspec(dllexport)
   #elif defined(USEDLL)
   #  define INTERFACE __declspec(dllimport)
   #else
   #  define INTERFACE
   #endif

   INTERFACE int foo();
   -------------

   --- foo.c ---
   #include "foo.h"

   int foo() { return 1; }
   -------------

   --- bar.c ---
   #include "foo.h"

   int main() { return foo(); }
   --------------

Now you are only maintaining the declaration of foo() in one place: foo.h.

To compile bar.exe to statically link in foo():

   gcc -c foo.c -o foo.o
   gcc -c bar.c -o bar.o
   gcc foo.o bar.o -o bar.exe

To compile foo() into a DLL:

   gcc -DMAKEDLL -c foo.c -o foo.o
   gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o

To compile bar.exe to use the DLL:

   gcc -DUSEDLL -c bar.c -o bar.exe
   gcc bar.o libfoo.import.a -o bar.exe

That's all there is to it.

(1)functions, methods and variables in structs / classes, external
   variables
(2)available to programs that use the DLL
(3)function prototypes, class definitions, etc.-- the stuff found in
   your header files

Hope this helps,
Carl Thompson

PS: for structs / classes instead of doing this:

   class foo {
     public:
       INTERFACE int bar;
       INTERFACE int baz;
   }

You can do this:

   class INTERFACE foo {
     public:
       int bar;
       int baz;
   }

They are both equivalent, but the second way is cleaner.

PPS: I've heard you can do the same thing using separate ".DEF" files, 
     but I don't know about that.

PPPS: None of this is necessary with reasonable operating systems, such
      as Unix or Linux.  The compiler and linker automatically export
      and import all externally visible symbols when building or using
      DLLs (shared libraries).  You don't even need a separate import
      library.

> ...

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Where can I get Cygwin 20.1b?

[MarketLogix]

I don't know where the "b" came from, not at all familiar w/that.

Isn't this just what's known as the old full.exe, circa 9801203 ?

This is what I still use (with egcs 1.1.1 release) and I'm
still rolling along just fine.

Here's my uname: 20.1 (0.3/1/1) 1998-12-3

Its good reliable stuff, I'm still hiding behind it.

bisk


Begin forwarded message:

Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
List-Subscribe: < mailto:cygwin-subscribe@sourceware.cygnus.com >
List-Archive: < http://sourceware.cygnus.com/ml/cygwin/ >
List-Post: < mailto:cygwin@sourceware.cygnus.com >
List-Help: < mailto:cygwin-help@sourceware.cygnus.com >,  
< http://sourceware.cygnus.com/ml/#faqs >
Sender: cygwin-owner@sourceware.cygnus.com
Delivered-To: mailing list cygwin@sourceware.cygnus.com
X-Originating-IP: [160.149.21.20]
From: "Bradley Smith" <brad2010@hotmail.com>
To: cygwin@sourceware.cygnus.com
Subject: Where can I get Cygwin 20.1b?
Date: Tue, 13 Jun 2000 15:53:57 PDT

I'm trying to make a ".dll" so that I can run the JNI and interface some C++ 
code with some Java code...

Here is the site I found some code :
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html

That demonstrates how this works.   HERE IS MY PROBLEM: When I run the
already compiled code examples that come with the "dll helpers from that web 
site",  it works FINE! which tells me that the .dll that *someone* created
is valid.   Yet when *I* try to compile the code, and create the .dll
myself; it fails.   I believe it's because I don't have the right version of 
Cygwin (which it recommends 20.1b  or better)   and therefore I don't have
the right version of egcs (which is recommended 1.1.1) where my version
shows I have 1.1

I'm told that Cygwin 20.1b is the version I need to be running because it
contains egcs 1.1.1 and apparently I dont' have that version because when I
do "gcc -v" it tells me I have egcs 1.1   not  egcs 1.1.1

I've downloaded the  Cygwin 20b apparently (from the "latest" release
directory on cygwin's ftp site and installed it...   but when I do  "uname
-a"  it tells me I have 20.1....    I'm so confused...  since even during
the Install process it tells me I am installing just version 20b.

I tried to installed egcs separately (newest version) thinking that would
fix my problem that I'm having  (lack of egcs version 1.1.1); but I can't
seem to get that installed to see if that fixes my problem.

So I'm thinking that if I just got the full version of cygwin (the 20.1b
version) everything should work fine..


Can someone please help me find the full version of 20.1 ???
I tried going to the Cygwin ftp site, and downloading what it says is the
"latest".. but when I install it   it only says it's version 20.   I even
tried downloading the  ".dll" upgrade that "supposedly" upgrades me from 20  
to 20.1    but that seems to make no difference in the compile results
problem that I'm having..

Help Please!!

thanks

-Brian

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Where can I get Cygwin 20.1b?

[Carl Thompson]

Bradley Smith wrote:
> 
> I'm trying to make a ".dll" so that I can run the JNI and interface
> some C++ code with some Java code...
> 
> Here is the site I found some code :
> http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html

With newer versions of GCC (and Cygwin) you can create DLLs much more easily
without the need for dllhelpers.  You would use something like

   gcc -Wl,--out-implib,libtest.import.a -shared -o test.dll test.o

This would create "test.dll" with from the object file "test.o" .  It will
also create an import library for the DLL (libtest.import.a).

(Of course, you still need to add the prefixes "__declspec(dllexport)" and
"__declspec(dllimport)" to your headers as needed.)

To use the new easy method, you need a newer version of GCC, not EGCS.  If
you are developing an application that uses the Cygwin DLL, the latest
version available from http://sourceware.cygnus.com/cygwin should work fine
for you.  If you need to create strictly Windows applications / DLLs without
any Unix compatibilty stuff, you can grab an updated version of b20.1 from
my site at http://www.carlthompson.net/cygwin .  I know it works to build
DLLs because I use it myself.

> ...

> thanks
> 
> -Brian

Hope this helps,
Carl Thompson

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Where can I get Cygwin 20.1b?

[Bradley Smith]

I'm trying to make a ".dll" so that I can run the JNI and interface some C++ 
code with some Java code...

Here is the site I found some code :
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html

That demonstrates how this works.   HERE IS MY PROBLEM: When I run the 
already compiled code examples that come with the "dll helpers from that web 
site",  it works FINE! which tells me that the .dll that *someone* created 
is valid.   Yet when *I* try to compile the code, and create the .dll 
myself; it fails.   I believe it's because I don't have the right version of 
Cygwin (which it recommends 20.1b  or better)   and therefore I don't have 
the right version of egcs (which is recommended 1.1.1) where my version 
shows I have 1.1

I'm told that Cygwin 20.1b is the version I need to be running because it 
contains egcs 1.1.1 and apparently I dont' have that version because when I 
do "gcc -v" it tells me I have egcs 1.1   not  egcs 1.1.1

I've downloaded the  Cygwin 20b apparently (from the "latest" release 
directory on cygwin's ftp site and installed it...   but when I do  "uname 
-a"  it tells me I have 20.1....    I'm so confused...  since even during 
the Install process it tells me I am installing just version 20b.

I tried to installed egcs separately (newest version) thinking that would 
fix my problem that I'm having  (lack of egcs version 1.1.1); but I can't 
seem to get that installed to see if that fixes my problem.

So I'm thinking that if I just got the full version of cygwin (the 20.1b 
version) everything should work fine..


Can someone please help me find the full version of 20.1 ???
I tried going to the Cygwin ftp site, and downloading what it says is the 
"latest".. but when I install it   it only says it's version 20.   I even 
tried downloading the  ".dll" upgrade that "supposedly" upgrades me from 20  
to 20.1    but that seems to make no difference in the compile results 
problem that I'm having..

Help Please!!

thanks

-Brian
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com