Re: Building C++ library DLL

Re: Building C++ library DLL

[Vincent Penne]

Thanks again for quick answer !

> > But with a more complicate library, I still have some internal
compiler
> > error when using class that are defined as
> > class __declspec(dllimport) foo
>
> This is of course illegal. You cannot *define* an imported class.
That's
> where all those preprocessor macros come in -- you declare when
importing,
> define when exporting.

Here I am a bit surprised. What I am doing,, and have seen done often,
is something like this

#ifdef LIBRARY
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif

The library is compiled with the LIBRARY symbol set, and the header
files contains things of that sort

class API foo {
 ...
};

API void some_function();

When the library is used, the same header files are used. Do you mean
that doing this is not allowed ? I should rather do

#ifdef LIBRARY
#define API  /* nothing */
#else
#define API __declspec(dllimport)
#endif
#define DECL_API __declspec(dllexport)

and then in sources of the library,

DECL_API void some_function()
{
 ...
}

This is of course a lot more annoying for the programmer when porting
from a unix library where no such stupid things are necessary ...

MSVC++ allow the first method ...



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

Shared Libraries

[Nicholas Codignotto]

I've been told that shared libraries under unix can be built with unresolved
externals. Thus, if I were to build a shared library with gcc under a
unix/cygwin system, I would not need a stub library file containing the
routines that I call within my library.

The vendor have me a header file and a Win32 library file (.lib) and nothing
else. The vendor states that under UNIX, no lib is needed. I can't figure
out how to correctly link my shared library as gcc under cygwin still
returns an "unresolved reference error".

I have a vendor-provided header (vendor.h) defining some structures and
functions. I compile my program like so:

	gcc -c my_module.c -o my_module.o
	gcc -shared -o my_module.so my_module.o

I then get an "unresolved reference" error for each function defined in
vendor.h that I call in my_module.c.

Thanks (in advance) a MILLION for any help!

Nick


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

Re: Building C++ library DLL

[Vincent Penne]

Thanks again for quick answer !

> > But with a more complicate library, I still have some internal
compiler
> > error when using class that are defined as
> > class __declspec(dllimport) foo
>
> This is of course illegal. You cannot *define* an imported class.
That's
> where all those preprocessor macros come in -- you declare when
importing,
> define when exporting.

Here I am a bit surprised. What I am doing,, and have seen done often,
is something like this

#ifdef LIBRARY
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif

The library is compiled with the LIBRARY symbol set, and the header
files contains things of that sort

class API foo {
 ...
};

API void some_function();

When the library is used, the same header files are used. Do you mean
that doing this is not allowed ? I should rather do

#ifdef LIBRARY
#define API  /* nothing */
#else
#define API __declspec(dllimport)
#endif
#define DECL_API __declspec(dllexport)

and then in sources of the library,

DECL_API void some_function()
{
 ...
}

This is of course a lot more annoying for the programmer when porting
from a unix library where no such stupid things are necessary ...

MSVC++ allow the first method ...



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

Shared Libraries

[Nicholas Codignotto]

I've been told that shared libraries under unix can be built with unresolved
externals. Thus, if I were to build a shared library with gcc under a
unix/cygwin system, I would not need a stub library file containing the
routines that I call within my library.

The vendor have me a header file and a Win32 library file (.lib) and nothing
else. The vendor states that under UNIX, no lib is needed. I can't figure
out how to correctly link my shared library as gcc under cygwin still
returns an "unresolved reference error".

I have a vendor-provided header (vendor.h) defining some structures and
functions. I compile my program like so:

	gcc -c my_module.c -o my_module.o
	gcc -shared -o my_module.so my_module.o

I then get an "unresolved reference" error for each function defined in
vendor.h that I call in my_module.c.

Thanks (in advance) a MILLION for any help!

Nick


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

Re: Building C++ library DLL

[Mumit Khan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

"vincent penne" <vincent.penne@freesbee.fr> writes:
> 
> -----Message d'origine-----
> De : Mumit Khan <khan@nanotech.wisc.edu>
> À : vincent penne <vincent.penne@freesbee.fr>
> Cc : cygwin@sourceware.cygnus.com <cygwin@sourceware.cygnus.com>
> Date : vendredi 12 novembre 1999 18:12
> Objet : Re: Building C++ library DLL
> 
> 
> >
> >It should work. Why not just try it out?
> >
> >
> 
> I tryed on a simple example, and it turned out that one problem came from
> the fact that the extenstion of my objects was not .o but .dllo (it's
> because I was creating a static library at the same time).
> It seems dllwrap only works when it is given some .o objects ...
> 
> My simple example works then ...
> 
> But with a more complicate library, I still have some internal compiler
> error when using class that are defined as
> class __declspec(dllimport) foo

This is of course illegal. You cannot *define* an imported class. That's
where all those preprocessor macros come in -- you declare when importing,
define when exporting.

> 
> Here is an example of such message :
> 
> ././Fl_Menu_Type.cxx:469: Internal compiler error, output_operand_lossage
> `inval
> id expression as operand'
> 
> The line where it crashes is a declaration of a variable of type foo, it is
> not a variable of the library, but a variable of the program that uses it
> ...

There are a whole bunch of bugs and limitations of dllimport/dllexport
code when it comes to C++, and some of these are very hard to fix. One
particular one that has been reported here is especially troublesome --
when you import a class with virtual function, and derive from it in
user code, the vtable code is screwed up (since we can't just take the
address/offset of "this" pointer when the class is in the DLL).

I do hope others will jump in and try to fix this; I have very limited
free time right now, and this is going to take more than just a tweak.

> I am using gcc 2.95, but I encountered some internal errors with egcs too
> (however I'm not sure they were happening at the same points, I might try
> this now ...)

Please feel free to send me testcases. If it's over a few megabytes, please 
don't email me the whole thing -- I'll set up a temporary upload area.

I need to write up the list of known bugs. Hopefully this week sometime.

Regards,
Mumit


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

Re: Building C++ library DLL

[Vincent Penne]

Harm-Jan Zwinderman wrote :



>
>> Steve Jorgensen wrote:
>
>> I'm not sure if this happens for C++, because this only happened
>> for me, but I found that if things were exported more than once
>> from the library, the extra compiler directives for DLL's caused
>> the CD compiler (gcc 2.90?) to barf, so you might check to see
>> you're class isn't getting exported more than once.
>
>I think this is more complicated. I also get this error
>Internal compiler error, output_operand_lossage `invalid expression
> as operand'
>when importing classes.
>
>Using the save-temps flag I have not found any duplicate
exports/imports in my code using mingw32 gcc 2.95.1.

I would like to add that exactly the same internal error happen with
egcs in the b20.1 release of cygwin ...



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

Re: Building C++ library DLL

[Mumit Khan]

"vincent penne" <vincent.penne@freesbee.fr> writes:
> ------=_NextPart_000_0004_01BF2CD2.A9E3DBE0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi all,
> maybe it's not the correct list where to ask for since my problem is GCC =
> related, but I try anyway.
> 
> With Microst Visual C++ it is possible to write something like
> 
> class __declspec(dllexport) foo {
>     static int foo_var;
> 
>     void foo_function();
> }
> 
> This will export the function and the static variable without need to =
> put the __declspec(dllexport) on every line of the class definition.
> 
> When using the library, one can write
> 
> class __declspec(dllimport) foo {
>  ...
> 
> My question : Is it supposed to work with GCC too ? If not, are there =
> any plans to implement such a nice feature ? This make porting of C++ =
> library to windows a lot more easy, since there is a lot less __declspec =
> directive to put in the header files ...

It should work. Why not just try it out?

Regards,
Mumit


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

Re: Building C++ library DLL

[vincent penne]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

-----Message d'origine-----
De : Mumit Khan <khan@nanotech.wisc.edu>
À : vincent penne <vincent.penne@freesbee.fr>
Cc : cygwin@sourceware.cygnus.com <cygwin@sourceware.cygnus.com>
Date : vendredi 12 novembre 1999 18:12
Objet : Re: Building C++ library DLL


>
>It should work. Why not just try it out?
>
>

I tryed on a simple example, and it turned out that one problem came from
the fact that the extenstion of my objects was not .o but .dllo (it's
because I was creating a static library at the same time).
It seems dllwrap only works when it is given some .o objects ...

My simple example works then ...

But with a more complicate library, I still have some internal compiler
error when using class that are defined as
class __declspec(dllimport) foo

Here is an example of such message :

././Fl_Menu_Type.cxx:469: Internal compiler error, output_operand_lossage
`inval
id expression as operand'

The line where it crashes is a declaration of a variable of type foo, it is
not a variable of the library, but a variable of the program that uses it
...

I am using gcc 2.95, but I encountered some internal errors with egcs too
(however I'm not sure they were happening at the same points, I might try
this now ...)



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

Re: Building C++ library DLL

[Steve Jorgensen]

	I'm not sure if this happens for C++, because this only happened
	for me, but I found that if things were exported more than once
	from the library, the extra compiler directives for DLL's caused
	the CD compiler (gcc 2.90?) to barf, so you might check to see
	you're class isn't getting exported more than once.

						Steve

> -----Message d'origine-----
> >
> >It should work. Why not just try it out?
> >
> >

> I tryed on a simple example, and it turned out that one problem came from
> the fact that the extenstion of my objects was not .o but .dllo (it's
> because I was creating a static library at the same time).
> It seems dllwrap only works when it is given some .o objects ...

> My simple example works then ...

> But with a more complicate library, I still have some internal compiler
> error when using class that are defined as
> class __declspec(dllimport) foo

> Here is an example of such message :

> ././Fl_Menu_Type.cxx:469: Internal compiler error, output_operand_lossage
> `inval
> id expression as operand'

> The line where it crashes is a declaration of a variable of type foo, it is
> not a variable of the library, but a variable of the program that uses it
> ...

> I am using gcc 2.95, but I encountered some internal errors with egcs too
> (however I'm not sure they were happening at the same points, I might try
> this now ...)



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


-----------------------------------------------------------
Steven Jorgensen      steve@khoral.com	    steve@haunt.com
------------------------------+----------------------------
Khoral Research Inc.          | PHONE: (505) 837-6500
6200 Uptown Blvd, Suite 200   | FAX:   (505) 881-3842
Albuquerque, NM 87110         | URL: http://www.khoral.com/
-----------------------------------------------------------

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

Re: Building C++ library DLL

[bughz]

> Steve Jorgensen wrote:

> I'm not sure if this happens for C++, because this only happened
> for me, but I found that if things were exported more than once
> from the library, the extra compiler directives for DLL's caused
> the CD compiler (gcc 2.90?) to barf, so you might check to see
> you're class isn't getting exported more than once.

I think this is more complicated. I also get this error
Internal compiler error, output_operand_lossage `invalid expression
 as operand'
when importing classes.

Using the save-temps flag I have not found any duplicate exports/imports in my code using mingw32 gcc 2.95.1.
I seem to get it on 'small' classes.
But I must admit, I have not done much testing on it.

Perhaps it also is worth while to check message
http://sourceware.cygnus.com/ml/cygwin/1999-10/msg00539.html
in which a small test case is provided.

Regards,
Harm-Jan Zwinderman




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

Building C++ library DLL

[vincent penne]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

Hi all,
maybe it's not the correct list where to ask for 
since my problem is GCC related, but I try anyway.
 
With Microst Visual C++ it is possible to write 
something like
 
class __declspec(dllexport) foo {
    static int 
foo_var;
 
    void 
foo_function();
}
 
This will export the function and the static 
variable without need to put the __declspec(dllexport) on every line of the 
class definition.
 
When using the library, one can 
write
 

class __declspec(dllimport) foo {
 ...
 
My question : Is it supposed to work with GCC 
too ? If not, are there any plans to implement such a nice feature ? This make 
porting of C++ library to windows a lot more easy, since there is a lot less 
__declspec directive to put in the header files ...
 

Re: Building C++ library DLL

[Mumit Khan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

"vincent penne" <vincent.penne@freesbee.fr> writes:
> 
> -----Message d'origine-----
> De : Mumit Khan <khan@nanotech.wisc.edu>
> À : vincent penne <vincent.penne@freesbee.fr>
> Cc : cygwin@sourceware.cygnus.com <cygwin@sourceware.cygnus.com>
> Date : vendredi 12 novembre 1999 18:12
> Objet : Re: Building C++ library DLL
> 
> 
> >
> >It should work. Why not just try it out?
> >
> >
> 
> I tryed on a simple example, and it turned out that one problem came from
> the fact that the extenstion of my objects was not .o but .dllo (it's
> because I was creating a static library at the same time).
> It seems dllwrap only works when it is given some .o objects ...
> 
> My simple example works then ...
> 
> But with a more complicate library, I still have some internal compiler
> error when using class that are defined as
> class __declspec(dllimport) foo

This is of course illegal. You cannot *define* an imported class. That's
where all those preprocessor macros come in -- you declare when importing,
define when exporting.

> 
> Here is an example of such message :
> 
> ././Fl_Menu_Type.cxx:469: Internal compiler error, output_operand_lossage
> `inval
> id expression as operand'
> 
> The line where it crashes is a declaration of a variable of type foo, it is
> not a variable of the library, but a variable of the program that uses it
> ...

There are a whole bunch of bugs and limitations of dllimport/dllexport
code when it comes to C++, and some of these are very hard to fix. One
particular one that has been reported here is especially troublesome --
when you import a class with virtual function, and derive from it in
user code, the vtable code is screwed up (since we can't just take the
address/offset of "this" pointer when the class is in the DLL).

I do hope others will jump in and try to fix this; I have very limited
free time right now, and this is going to take more than just a tweak.

> I am using gcc 2.95, but I encountered some internal errors with egcs too
> (however I'm not sure they were happening at the same points, I might try
> this now ...)

Please feel free to send me testcases. If it's over a few megabytes, please 
don't email me the whole thing -- I'll set up a temporary upload area.

I need to write up the list of known bugs. Hopefully this week sometime.

Regards,
Mumit


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

Re: Building C++ library DLL

[Vincent Penne]

Harm-Jan Zwinderman wrote :



>
>> Steve Jorgensen wrote:
>
>> I'm not sure if this happens for C++, because this only happened
>> for me, but I found that if things were exported more than once
>> from the library, the extra compiler directives for DLL's caused
>> the CD compiler (gcc 2.90?) to barf, so you might check to see
>> you're class isn't getting exported more than once.
>
>I think this is more complicated. I also get this error
>Internal compiler error, output_operand_lossage `invalid expression
> as operand'
>when importing classes.
>
>Using the save-temps flag I have not found any duplicate
exports/imports in my code using mingw32 gcc 2.95.1.

I would like to add that exactly the same internal error happen with
egcs in the b20.1 release of cygwin ...



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

Re: Building C++ library DLL

[bughz]

> Steve Jorgensen wrote:

> I'm not sure if this happens for C++, because this only happened
> for me, but I found that if things were exported more than once
> from the library, the extra compiler directives for DLL's caused
> the CD compiler (gcc 2.90?) to barf, so you might check to see
> you're class isn't getting exported more than once.

I think this is more complicated. I also get this error
Internal compiler error, output_operand_lossage `invalid expression
 as operand'
when importing classes.

Using the save-temps flag I have not found any duplicate exports/imports in my code using mingw32 gcc 2.95.1.
I seem to get it on 'small' classes.
But I must admit, I have not done much testing on it.

Perhaps it also is worth while to check message
http://sourceware.cygnus.com/ml/cygwin/1999-10/msg00539.html
in which a small test case is provided.

Regards,
Harm-Jan Zwinderman




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

Re: Building C++ library DLL

[Steve Jorgensen]

	I'm not sure if this happens for C++, because this only happened
	for me, but I found that if things were exported more than once
	from the library, the extra compiler directives for DLL's caused
	the CD compiler (gcc 2.90?) to barf, so you might check to see
	you're class isn't getting exported more than once.

						Steve

> -----Message d'origine-----
> >
> >It should work. Why not just try it out?
> >
> >

> I tryed on a simple example, and it turned out that one problem came from
> the fact that the extenstion of my objects was not .o but .dllo (it's
> because I was creating a static library at the same time).
> It seems dllwrap only works when it is given some .o objects ...

> My simple example works then ...

> But with a more complicate library, I still have some internal compiler
> error when using class that are defined as
> class __declspec(dllimport) foo

> Here is an example of such message :

> ././Fl_Menu_Type.cxx:469: Internal compiler error, output_operand_lossage
> `inval
> id expression as operand'

> The line where it crashes is a declaration of a variable of type foo, it is
> not a variable of the library, but a variable of the program that uses it
> ...

> I am using gcc 2.95, but I encountered some internal errors with egcs too
> (however I'm not sure they were happening at the same points, I might try
> this now ...)



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


-----------------------------------------------------------
Steven Jorgensen      steve@khoral.com	    steve@haunt.com
------------------------------+----------------------------
Khoral Research Inc.          | PHONE: (505) 837-6500
6200 Uptown Blvd, Suite 200   | FAX:   (505) 881-3842
Albuquerque, NM 87110         | URL: http://www.khoral.com/
-----------------------------------------------------------

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

Re: Building C++ library DLL

[vincent penne]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

-----Message d'origine-----
De : Mumit Khan <khan@nanotech.wisc.edu>
À : vincent penne <vincent.penne@freesbee.fr>
Cc : cygwin@sourceware.cygnus.com <cygwin@sourceware.cygnus.com>
Date : vendredi 12 novembre 1999 18:12
Objet : Re: Building C++ library DLL


>
>It should work. Why not just try it out?
>
>

I tryed on a simple example, and it turned out that one problem came from
the fact that the extenstion of my objects was not .o but .dllo (it's
because I was creating a static library at the same time).
It seems dllwrap only works when it is given some .o objects ...

My simple example works then ...

But with a more complicate library, I still have some internal compiler
error when using class that are defined as
class __declspec(dllimport) foo

Here is an example of such message :

././Fl_Menu_Type.cxx:469: Internal compiler error, output_operand_lossage
`inval
id expression as operand'

The line where it crashes is a declaration of a variable of type foo, it is
not a variable of the library, but a variable of the program that uses it
...

I am using gcc 2.95, but I encountered some internal errors with egcs too
(however I'm not sure they were happening at the same points, I might try
this now ...)



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

Re: Building C++ library DLL

[Mumit Khan]

"vincent penne" <vincent.penne@freesbee.fr> writes:
> ------=_NextPart_000_0004_01BF2CD2.A9E3DBE0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi all,
> maybe it's not the correct list where to ask for since my problem is GCC =
> related, but I try anyway.
> 
> With Microst Visual C++ it is possible to write something like
> 
> class __declspec(dllexport) foo {
>     static int foo_var;
> 
>     void foo_function();
> }
> 
> This will export the function and the static variable without need to =
> put the __declspec(dllexport) on every line of the class definition.
> 
> When using the library, one can write
> 
> class __declspec(dllimport) foo {
>  ...
> 
> My question : Is it supposed to work with GCC too ? If not, are there =
> any plans to implement such a nice feature ? This make porting of C++ =
> library to windows a lot more easy, since there is a lot less __declspec =
> directive to put in the header files ...

It should work. Why not just try it out?

Regards,
Mumit


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

Building C++ library DLL

[vincent penne]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

Hi all,
maybe it's not the correct list where to ask for 
since my problem is GCC related, but I try anyway.
 
With Microst Visual C++ it is possible to write 
something like
 
class __declspec(dllexport) foo {
    static int 
foo_var;
 
    void 
foo_function();
}
 
This will export the function and the static 
variable without need to put the __declspec(dllexport) on every line of the 
class definition.
 
When using the library, one can 
write
 

class __declspec(dllimport) foo {
 ...
 
My question : Is it supposed to work with GCC 
too ? If not, are there any plans to implement such a nice feature ? This make 
porting of C++ library to windows a lot more easy, since there is a lot less 
__declspec directive to put in the header files ...