example: ------------------------------------------------- main.cpp #include <stdio.h> #include <windows.h> extern "C" __declspec(dllimport) void xxx(char *str, ...); extern "C" __declspec(dllimport) char *zzz; int WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR szCmdLine, int) { xxx("blahblah\n", 1, 2, 3); printf(zzz); return 0; } --------------------------------------------------- mylib.cpp #include <stdio.h> #include <windows.h> extern "C" __declspec(dllexport) void xxx(char *str, ...); char zzz[80]; void xxx(char *str, ...) { printf(str); lstrcpy(zzz, "12345\n"); printf(zzz); } ---------------------------------------------------- mylib.dll.spec @ varargs xxx(str) @ extern zzz ----------------------------------------------------- mylib.cpp compiled successfully in mylib.dll.so main.cpp compiler error: undefined reference to `zzz' What I do wrong ??? How to export variables ??? And another question: how can i export functions such as ClassName::Function();
Am Fre, 2003-08-08 um 13.23 schrieb flyker:
extern "C" __declspec(dllimport) void xxx(char *str, ...); extern "C" __declspec(dllimport) char *zzz;
Except on CygWin/MingW, gcc has no support for __declspec(dllimport) and __declspec(dllexport). If I understand Dimi right, enabling DLL compilation with winegcc/winewrap is on his to-do list. I have also looked into this recently and found ts hard to do right. Best thing right now is probably to write a "def" file manually. If you have access to a MingW/cygwin system, you can create one their with dlltool or ld. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
On August 8, 2003 08:27 am, Martin Wilck wrote:
Best thing right now is probably to write a "def" file manually. If you have access to a MingW/cygwin system, you can create one their with dlltool or ld.
Yes, this is good advice for the forseable future. Without compiler support, we can't do much about the dllimport/dllexport bit. -- Dimi.
Am Fre, 2003-08-08 um 14.32 schrieb Dimitrie O. Paun:
Yes, this is good advice for the forseable future. Without compiler support, we can't do much about the dllimport/dllexport bit.
This means that, with the introduction of .def files in wine, porting software (especially C++) with winelib has become considerably more troublesome than before. Whatever we think about dllexport, it is widely used by Windows programmers. binutils with PE support can be used to extract a .def file with all symbols from an object file right now. Unfortunately, binutils on most standard Linux distributions do not support PE. But it may be acceptable to demand that winelib developers recompile their binutils. Btw Dimi, is their any specific reason why winewrap/winegcc are written in C rather than in some scripting language like bash or perl? I'd think that winewrap/winegcc scripts would be much easier to maintain and customize than the current C code, and would actually be the adequate tool for the job. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Martin Wilck wrote:
Btw Dimi, is their any specific reason why winewrap/winegcc are written in C rather than in some scripting language like bash or perl? I'd think that winewrap/winegcc scripts would be much easier to maintain and customize than the current C code, and would actually be the adequate tool for the job.
Martin
Hay I .. my thought exactly for a long time. a bash case statment and a "--include ms_extentions.h" is all that is needed. And is much more self explanetory. (and fixable)
On August 18, 2003 05:12 am, Martin Wilck wrote:
This means that, with the introduction of .def files in wine, porting software (especially C++) with winelib has become considerably more troublesome than before. Whatever we think about dllexport, it is widely used by Windows programmers.
I know, it is unfortunate, but without compiler support, there is little we can do I'm afraid. If anyone has any ideas on how we can work around this, I'm all ears...
binutils with PE support can be used to extract a .def file with all symbols from an object file right now. Unfortunately, binutils on most standard Linux distributions do not support PE. But it may be acceptable to demand that winelib developers recompile their binutils.
That's what I've been thinking about too. Maybe it's time to try to convince various distributions to include PE support by default...
Btw Dimi, is their any specific reason why winewrap/winegcc are written in C rather than in some scripting language like bash or perl? I'd think that winewrap/winegcc scripts would be much easier to maintain and customize than the current C code, and would actually be the adequate tool for the job.
First, I don't know perl, so that was not an option. As for bash, the kind of argument manipulations we're doing are not easily achieved in bash, and it seemed it would have been cleaner to do it in C. I still stand by this opinion. Moreover, it seems that C is way more prefered (on average) than scripting languages, and in fact it's a better way of inviting contributions. See the latest attempt to use Perl for our conformance tests... -- Dimi.
Am Mon, 2003-08-18 um 14.24 schrieb Dimitrie O. Paun:
First, I don't know perl, so that was not an option. As for bash, the kind of argument manipulations we're doing are not easily achieved in bash, and it seemed it would have been cleaner to do it in C.
I am not sure what manipulations you're talking about; AFAICS the hard stuff is done by winebuild anyway. What I don't like about C in this case is that all the low-level stuff (realloc() and friends) makes the code hard to read and prone to buffer overflows and the like. Anyway, you do the work, you decide.
Moreover, it seems that C is way more prefered (on average) than scripting languages, and in fact it's a better way of inviting contributions. See the latest attempt to use Perl for our conformance tests...
Yeah, the wine guys like low-level coding :-) Perhaps I'll contribute a bash version of winewrap soon, just for fun. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Perhaps I'll contribute a bash version of winewrap soon, just for fun.
Avoid 'bash'isms, not everyone has, or even wants to run, bash. It ought to be possible to keep to the posix shell rules. (bash is completely broken wrt the only standard for shells) David -- David Laight: david(a)l8s.co.uk
On 18 Aug 2003, Martin Wilck wrote:
I am not sure what manipulations you're talking about;
Look at winegcc.c. If we do that one in C, it just makes sense to do winewrap in C as well. Plus it's more extensible for the future, me thinks.
AFAICS the hard stuff is done by winebuild anyway. What I don't like about C in this case is that all the low-level stuff (realloc() and friends) makes the code hard to read and prone to buffer overflows and the like.
There is a patch pending which removes most of that. Not a biggy, really.
Yeah, the wine guys like low-level coding :-) Perhaps I'll contribute a bash version of winewrap soon, just for fun.
Try doing winegcc in standard sh, I doubt you'll get any shorter/cleaner code. Not to mention a bit slower :) -- Dimi.
Am Die, 2003-08-19 um 00.36 schrieb Dimitrie O. Paun:
Try doing winegcc in standard sh, I doubt you'll get any shorter/cleaner code. Not to mention a bit slower :)
You challenged me :-) really, shell coding is one of my favorites. Have a look at the attached code, if you like. Actually, I found it easier to mimic winegcc than wineld. For C++ code, a link winec++ -> winecc needs to be created. I have added a few enhancements, such as dealing with non-standard Wine installation directories, running from a Wine source tree, and more sophisticated debug output. Therefore, the code indeed isn't shorter than the C code. IMO it is more readable and to the point, though - but that's of course a matter of taste. I found that paths in the original winegcc/winewrap are broken for my wine/linux installation, so the paths that I put in these scripts may be broken for MingW. They can be easily customized with environment variables, though; see bottom of winetools.sh. All three files must be somewhere in the PATH. Everyone is invited to try this stuff out. I ran it with bash, ash, zsh, and pdksh here, so I guess it must be fairly portable. Please send bug reports to my email address because I'am not reading wine-devel on a daily basis. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
On August 21, 2003 05:08 pm, Martin Wilck wrote:
You challenged me :-) really, shell coding is one of my favorites.
This is very nice Martin, I'll grant you that. However I'm afraid I'm not sold. And I'm saying this without any emotional attachment to my code :). But let me explain why: -- I think we're ending up raising the bar rather than lowering it. For most developers, winegcc.c is a tiny C program they can easily understand and modify. For the same group, yours is a non-trivial script. -- winegcc.c is portable and will run without problems on all systems, even on Windows. On the other hand, for scripts of this size it's very easy to add features that will break on some implementations, or that are bash specific. Moreover, we don't find out about them until a user tries to run the program, at runtime. -- the result is not smaller. Some things are cleaner, true, but I don't think the .c program was that unreadable :) -- last, but not least, the thing is for sure slower. Maybe not by much, but I think it's measurable, once we compile Wine with winegcc. I, for one, am more confortable with the C semantics, rather than sh. I can right sh scripts, but I'm not in my element doing non trivial stuff (or maybe I'm more confortable in C :)). Anyway, just my .02$ -- I guess it's Alexandre's call. -- Dimi.
Martin Wilck wrote:
Am Fre, 2003-08-08 um 13.23 schrieb flyker:
extern "C" __declspec(dllimport) void xxx(char *str, ...); extern "C" __declspec(dllimport) char *zzz;
Except on CygWin/MingW, gcc has no support for __declspec(dllimport) and __declspec(dllexport).
If I understand Dimi right, enabling DLL compilation with winegcc/winewrap is on his to-do list.
I have also looked into this recently and found ts hard to do right.
Best thing right now is probably to write a "def" file manually. If you have access to a MingW/cygwin system, you can create one their with dlltool or ld.
Martin
Ok. I understand. But i never write "def" files manually... --------------------------------------------------------- libmylib.def ; File generated automatically from mylib.dll.spec; do not edit! LIBRARY mylib.dll EXPORTS xxx @1 zzz @2 DATA ---------------------------------------------------------- What wrong here ? I have ld. I can create "def" files by using ld ?
flyker <flyker(a)everys.com> writes:
mylib.cpp compiled successfully in mylib.dll.so main.cpp compiler error: undefined reference to `zzz'
What I do wrong ??? How to export variables ???
You can export them but you can't import them from a Winelib app, since the standard gcc doesn't support the dllimport mechanism. I doubt this will be supported anytime soon. -- Alexandre Julliard julliard(a)winehq.com
participants (7)
-
Alexandre Julliard -
Boaz Harrosh -
David Laight -
Dimitrie O. Paun -
Dimitrie O. Paun -
flyker -
Martin Wilck