From: Rob K. <ca...@ca...> - 2002-07-03 09:36:08
|
Hello, some of the users of my applications have asked for MinGW support and I'd like to offer it to them. Is there a tutorial available on necessary changes to existing UNIX applications to build correctly or is an actual complete port necessary? Adding some #ifdef's and making necessary changes to the configure scripts is not a problem for me, but I currently do not have the resources to work on a full port. (in case you wonder, it is regarding monopd (http://unixcode.org/monopd/) and one or two of the dependency libraries) Regards, Rob -- Rob Kaper | Gimme some love, gimme some skin, ca...@ca... | if we ain't got that then we ain't got much www.capsi.com | and we ain't got nothing, nothing! -- "Nothing" by A |
From: Luke D. <cod...@ho...> - 2002-07-03 09:55:13
|
----- Original Message ----- From: "Rob Kaper" <ca...@ca...> To: <min...@li...> Sent: Wednesday, July 03, 2002 5:36 PM Subject: [Mingw-users] Making UNIX apps out of the box > Hello, some of the users of my applications have asked for MinGW support and > I'd like to offer it to them. Is there a tutorial available on necessary > changes to existing UNIX applications to build correctly or is an actual > complete port necessary? > > Adding some #ifdef's and making necessary changes to the configure scripts is > not a problem for me, but I currently do not have the resources to work on a > full port. The degree of porting required depends a lot on how your code is written, but in general there _could_ be a lot of work needed. However, porting your application to Cygwin should take considerably less effort, as this is what Cygwin is designed for. I am not aware of any general tutorial on porting Unix applications to Windows, but there is likely information on specific topics (e.g. porting sockets programs). It can't hurt to attempt to build it on Windows, so if you try it first (or find someone else to do it) you can ask more specific questions about configuring and porting. > > (in case you wonder, it is regarding monopd (http://unixcode.org/monopd/) > and one or two of the dependency libraries) > > Regards, > Rob > -- > Rob Kaper | Gimme some love, gimme some skin, > ca...@ca... | if we ain't got that then we ain't got much > www.capsi.com | and we ain't got nothing, nothing! -- "Nothing" by A Luke Dunstan |
From: Earnie B. <ear...@ya...> - 2002-07-03 10:41:04
|
Luke Dunstan wrote: > > ----- Original Message ----- > From: "Rob Kaper" <ca...@ca...> > To: <min...@li...> > Sent: Wednesday, July 03, 2002 5:36 PM > Subject: [Mingw-users] Making UNIX apps out of the box > > > Hello, some of the users of my applications have asked for MinGW support > and > > I'd like to offer it to them. Is there a tutorial available on necessary > > changes to existing UNIX applications to build correctly or is an actual > > complete port necessary? > > > > Adding some #ifdef's and making necessary changes to the configure scripts > is > > not a problem for me, but I currently do not have the resources to work on > a > > full port. > > The degree of porting required depends a lot on how your code is written, > but in general there _could_ be a lot of work needed. However, porting your > application to Cygwin should take considerably less effort, as this is what > Cygwin is designed for. The users want MinGW, I.E.: no Cygwin. > I am not aware of any general tutorial on porting > Unix applications to Windows, but there is likely information on specific > topics (e.g. porting sockets programs). It can't hurt to attempt to build it > on Windows, so if you try it first (or find someone else to do it) you can > ask more specific questions about configuring and porting. > I googled for "porting POSIX to Win32" and found numerous references. This is one of the better http://www.informatik.uni-stuttgart.de/menschen/sommersn_public/unix2nt.html Earnie. |
From: Mike T. <mi...@br...> - 2002-07-11 01:14:02
|
Hi all. I'm working on Gnu Common Lisp with Mingw32 and have noted that some old MSVC ifdefs in the memory management code redefine a function called "heap_init" so that it does nothing. This function appears not to be part of Mingw32 (according to fgrep -r heap_init). Does anyone know whether this would be a potential source of problems if I ignored it or whether there are equivalent functions in Mingw32? Cheers Mike Thomas |
From: Luke D. <cod...@ho...> - 2002-07-11 02:00:07
|
Since heap_init appears to be a Cygwin function it naturally is not found in the Mingw headers. It should probably be redefined to do nothing for any non-Cygwin platform (#ifndef __CYGWIN__), if indeed this works for MSVC. I expect that the person who wrote the code would be able to help more, and the Cygwin documentation should too. Luke Dunstan ----- Original Message ----- From: "Mike Thomas" <mi...@br...> To: <min...@li...> Sent: Thursday, July 11, 2002 9:09 AM Subject: [Mingw-users] heap_init > Hi all. > > I'm working on Gnu Common Lisp with Mingw32 and have noted that some old > MSVC ifdefs in the memory management code redefine a function called > "heap_init" so that it does nothing. > > This function appears not to be part of Mingw32 (according to fgrep -r > heap_init). > > Does anyone know whether this would be a potential source of problems if I > ignored it or whether there are equivalent functions in Mingw32? > > Cheers > > Mike Thomas |
From: Mike T. <mi...@br...> - 2002-07-11 02:26:42
|
Thanks Luke. > Since heap_init appears to be a Cygwin function it naturally is not found in > the Mingw headers. It should probably be redefined to do nothing for any > non-Cygwin platform (#ifndef __CYGWIN__), if indeed this works for MSVC. I > expect that the person who wrote the code would be able to help more, and > the Cygwin documentation should too. > I was slightly inaccurate - it's _heap_init. That function certainly appears in the MSVC runtime eg using fgrep. ----------------------------------------------------------------- c:/devtools/msdev/VC98/CRT/SRC/HEAPINIT.C:*_heap_init() - Initialize the heap c:/devtools/msdev/VC98/CRT/SRC/HEAPINIT.C:int __cdecl _heap_init ( ----------------------------------------------------------------- The original author of the GCL Windows code is dead. The relevant code in GCL is: #if (_MSC_VER >= 1000) /* MSVC 4.2 invokes these functions from mainCRTStartup to initialize a heap via HeapCreate. They are normally defined by the runtime, but we override them here so that the unnecessary HeapCreate call is not performed. */ int __cdecl _heap_init (void) { /* Stepping through the assembly indicates that mainCRTStartup is expecting a nonzero success return value. */ return 1; } ........ ----- Original Message ----- From: "Luke Dunstan" <cod...@ho...> To: "Mike Thomas" <mi...@br...>; <min...@li...> Sent: Thursday, July 11, 2002 11:59 AM Subject: Re: [Mingw-users] heap_init > > Since heap_init appears to be a Cygwin function it naturally is not found in > the Mingw headers. It should probably be redefined to do nothing for any > non-Cygwin platform (#ifndef __CYGWIN__), if indeed this works for MSVC. I > expect that the person who wrote the code would be able to help more, and > the Cygwin documentation should too. > > Luke Dunstan > > ----- Original Message ----- > From: "Mike Thomas" <mi...@br...> > To: <min...@li...> > Sent: Thursday, July 11, 2002 9:09 AM > Subject: [Mingw-users] heap_init > > > > Hi all. > > > > I'm working on Gnu Common Lisp with Mingw32 and have noted that some old > > MSVC ifdefs in the memory management code redefine a function called > > "heap_init" so that it does nothing. > > > > This function appears not to be part of Mingw32 (according to fgrep -r > > heap_init). > > > > Does anyone know whether this would be a potential source of problems if I > > ignored it or whether there are equivalent functions in Mingw32? > > > > Cheers > > > > Mike Thomas > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Luke D. <cod...@ho...> - 2002-07-11 03:09:32
|
----- Original Message ----- From: "Mike Thomas" <mi...@br...> To: "Luke Dunstan" <cod...@ho...>; <min...@li...> Sent: Thursday, July 11, 2002 10:22 AM Subject: Re: [Mingw-users] heap_init > Thanks Luke. > > I was slightly inaccurate - it's _heap_init. That function certainly > appears in the MSVC runtime eg using fgrep. > > ----------------------------------------------------------------- > c:/devtools/msdev/VC98/CRT/SRC/HEAPINIT.C:*_heap_init() - Initialize the > heap > c:/devtools/msdev/VC98/CRT/SRC/HEAPINIT.C:int __cdecl _heap_init ( > > ----------------------------------------------------------------- Okay, but since _heap_init is not in the MS headers and is not exported by MSVCRT.DLL, it appears to be part of the static C library only. Does clisp work when built with MSVC using the DLL version of the C runtime? If so, there should be no need to change it for Mingw. But if it doesn't, then it will likely not work with Mingw either and will require modification (but I have no idea what changes they might be). > > The original author of the GCL Windows code is dead. The relevant code in > GCL is: > > #if (_MSC_VER >= 1000) > > /* MSVC 4.2 invokes these functions from mainCRTStartup to initialize > a heap via HeapCreate. They are normally defined by the runtime, > but we override them here so that the unnecessary HeapCreate call > is not performed. */ > > int __cdecl > _heap_init (void) > { > /* Stepping through the assembly indicates that mainCRTStartup is > expecting a nonzero success return value. */ > return 1; > } > > ........ > I'm sure you realise how troublesome code can be if it depends on undocumented internal details of a specific C library, and if you search for _heap_init() on Google you will find that apparently XEmacs Lisp had to be modified because this hack doesn't work in MSVC 7 either. I guess you will just have to try it and see... Luke |
From: Earnie B. <ear...@ya...> - 2002-07-03 10:30:57
|
Rob Kaper wrote: > > Hello, some of the users of my applications have asked for MinGW support and > I'd like to offer it to them. Is there a tutorial available on necessary > changes to existing UNIX applications to build correctly or is an actual > complete port necessary? > > Adding some #ifdef's and making necessary changes to the configure scripts is > not a problem for me, but I currently do not have the resources to work on a > full port. > > (in case you wonder, it is regarding monopd (http://unixcode.org/monopd/) > and one or two of the dependency libraries) > Looking at the description I don't see that it should be too difficult to port to a native (i.e., Cygwinless) Win32 environment using MinGW + MSYS. MSYS provides the Minimal SYStem to execute a typical configure script. Note, MinGW doesn't support POSIX only ANSI. Earnie. |
From: F. <j_r...@ya...> - 2002-07-03 10:44:11
|
On Wed, Jul 03, 2002 at 11:36:04AM +0200, Rob Kaper wrote: >Hello, some of the users of my applications have asked for MinGW support and >I'd like to offer it to them. Is there a tutorial available on necessary >changes to existing UNIX applications to build correctly or is an actual >complete port necessary? > >Adding some #ifdef's and making necessary changes to the configure scripts is >not a problem for me, but I currently do not have the resources to work on a >full port. > >(in case you wonder, it is regarding monopd (http://unixcode.org/monopd/) >and one or two of the dependency libraries) I've downloaded your application to analyze how difficult it would be to port to MinGW. As Luke said, you can always built it with Cygwin and be done with it, but this may not be what your users really want due to several reasons which I won't discuss here (perhaps the most important one is the dependency of the final result on Cygwin itself). The monopd application it's quite trivial to port to MinGW since it uses mostly standard C headers and has no GUI. The stuff that would require porting was (clevearly I may add) already encapsulated in the libcapsi_network, and basically consist of the sockets API. Porting this shouldn't be too hard as the Windows socket API is based on the BSD, but with different names, but it would take some investigation nevertheless (googling for "unix win32 socket porting" or see how other daemons that work on both unix/windows do will give all the info you need). But a thing I noticed was that the available client applications of monopd are quite a different story, as one depends on KDE, and other on GTK. The later may be possible to port since GTK is available for windows. (QT is too but it's not free.) So unless your users plan to come up with their own win32 native clients, then you really should stick to cygwin since KDE (and perhaps gnome too) are availble for it. I hope this helps. José Fonseca |
From: Rob K. <ca...@ca...> - 2002-07-03 10:58:51
|
On Wed, Jul 03, 2002 at 11:41:55AM +0100, José Fonseca wrote: <snip> Thanks for the effort, will read up on the pointers and see where I can start. What I'd love is to somehow keep both the original and the port in the same package and just have a --enable-winmg in the configure script, as that would be the easiest to maintain (I hate making seperate releases for stuff that is basically the same). > But a thing I noticed was that the available client applications of monopd > are quite a different story, as one depends on KDE, and other on GTK. The > later may be possible to port since GTK is available for windows. (QT is > too but it's not free.) So unless your users plan to come up with their > own win32 native clients, then you really should stick to cygwin since KDE > (and perhaps gnome too) are availble for it. The server was designed to support multiple clients and the reason why some users want a win32 version of monopd is actually because they can develop a native win32 client more easily. I have no intention of porting the KDE client to win32, although I make make a Qt/Embedded version of it later on. > I hope this helps. Not unlikely that it will. :) Thanks! Rob -- Rob Kaper | Gimme some love, gimme some skin, ca...@ca... | if we ain't got that then we ain't got much www.capsi.com | and we ain't got nothing, nothing! -- "Nothing" by A |
From: F. <j_r...@ya...> - 2002-07-03 11:23:35
|
On Wed, Jul 03, 2002 at 12:58:46PM +0200, Rob Kaper wrote: >On Wed, Jul 03, 2002 at 11:41:55AM +0100, José Fonseca wrote: ><snip> > >Thanks for the effort, will read up on the pointers and see where I can >start. What I'd love is to somehow keep both the original and the port in >the same package and just have a --enable-winmg in the configure script, as >that would be the easiest to maintain (I hate making seperate releases for >stuff that is basically the same). > That will surely be possible. There is already an autoconf macro AC_MINGW32, and you can solve most of the differences with "#ifdef __MINGW32__ ... #endif", and #define unix_open_socket WSAOpenSocket". (NOTE: I just made up these names because I know NULL about socket programming). See also http://sources.redhat.com/autobook/autobook/autobook_110.html#SEC110 . It refers to Cygwin, but most of the information there applies to MinGW too. Since you use Unix, it will be probably much easier for you to use a MinGW cross-compiler (and probably you can even run your app under WINE to test it). See http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/documentation/cross/ and http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/documentation/porting/ for some hints to do that. >> But a thing I noticed was that the available client applications of monopd >> are quite a different story, as one depends on KDE, and other on GTK. The >> later may be possible to port since GTK is available for windows. (QT is >> too but it's not free.) So unless your users plan to come up with their >> own win32 native clients, then you really should stick to cygwin since KDE >> (and perhaps gnome too) are availble for it. > >The server was designed to support multiple clients and the reason why some >users want a win32 version of monopd is actually because they can develop a >native win32 client more easily. That's what I though. > I have no intention of porting the KDE >client to win32, although I make make a Qt/Embedded version of it later on. > Well QT is available (as noncommercial use or demo) for Windows but as a binary only. This is for MSVC but is no good for MinGW due to the different C++ ABIs... José Fonseca |
From: Thomas G. <tg...@e-...> - 2002-07-04 15:29:29
|
Hello there, another beginner question ... I succeded building a DLL and did not create an exports file manually, instead the dlltool did it and it actually looks OK. When I now want to link the DLL against a test program, everything is fine except one global variable, which cannot be resolved: $ c++ -DPIC -o tstargs tstargs.o -L. -lim tstargs.o: In function `main': .../tstargs.C:31: undefined reference to `tge' The SL shows it as: $ nm ./libim.dll | grep tge 65c2057c D _tge and the file im.def says: $ grep tge ./im.def tge @ 462 DATA ; Any ideas? Many thanks in advance ... tge -- ................................................ Thomas Gentsch -------------- Phone: +49 711 486948 E-mail: tg...@e-... Mobil: +49 173 6620507 Fax: +49 711 4687889 WWW: www.e-tge.de ................................................ |
From: Luke D. <cod...@ho...> - 2002-07-05 01:53:55
|
The problem here is with importing data objects from the DLL rather than exporting. Ideally you should declare the data as __attribute__((dllimport)) when building the exe, but if that is not a simple task you may want to try the flag "-Wl,--enable-auto-import" when linking the exe. It is my understanding that it doesn't work in 100% of cases, but it is surely worth a try. Luke ----- Original Message ----- From: "Thomas Gentsch" <tg...@e-...> To: <min...@li...> Sent: Thursday, July 04, 2002 11:36 PM Subject: [Mingw-users] Exporting data objects from DLL > Hello there, > > another beginner question ... > > I succeded building a DLL and did not create an exports file manually, > instead the dlltool did it and it actually looks OK. > > When I now want to link the DLL against a test program, everything is > fine except one global variable, which cannot be resolved: > > $ c++ -DPIC -o tstargs tstargs.o -L. -lim > tstargs.o: In function `main': > .../tstargs.C:31: undefined reference to `tge' > > The SL shows it as: > > $ nm ./libim.dll | grep tge > 65c2057c D _tge > > and the file im.def says: > > $ grep tge ./im.def > tge @ 462 DATA ; > > Any ideas? Many thanks in advance ... > tge > > -- > ................................................ > Thomas Gentsch > -------------- > Phone: +49 711 486948 E-mail: tg...@e-... > Mobil: +49 173 6620507 > Fax: +49 711 4687889 WWW: www.e-tge.de > ................................................ > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Caffeinated soap. No kidding. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |