From: Castro, E. M. (USPC.PCT.Hopewell) <ECastro@NA2.US.ML.com> - 2001-10-30 17:22:12
|
Paul I am trying to understand exactly what is the problem you are trying to overcome. What are those deficiencies you speak of with Win32 DLL and MS compiler. Is it the fact that you would like to resolve unresolved references at run time?. There are two ways of doing this in WIN32. One is to explicitly load the DLL and ask for those entry point you require. The other is by "demand load" linking in which the DLL is only load if any entry point of such DLL is called as part of the execution of the program. Is it the fact that you want to use autotools?. I think there is a version of autotools compile for MINGW. -----Original Message----- From: Paul Gregory [mailto:PGr...@su...] Sent: Tuesday, October 30, 2001 11:26 AM To: 'min...@li...' Subject: [Mingw-users] Is MingW suitable for my needs. Hi all, I am involved in an Open Source project which is primarily Posix based. It uses Automake/Autoconf/libtool for its configuration management. I have been for some time maintaining a Win32 build of this project and it is becoming more and more difficult to overcome the deficiencies of the Microsoft compiler, in fact the latest set of changes highlight a major problem with the MS compiler which is going to prove very difficult to overcome in a manner which doesn't spread horribly throughout the whole codebase. For this reason I have decided to look into some alternatives to make keeping the Win32 build up to date simpler. I have looked into using Cygwin/XFree86, as this is a GUI application based around gtk+ and OpenGL, this sort of offers an option but for two issues. Firstly that the Win32 version would then require the user to have installed Cygwin and Cygwin/Xfree86 which is no small task just to have this one application. Secondly the project relies heavily on shared libraries, and in particular the Posix feature of having unresolved references in shared libraries which are resolved at runtime with the executable loading them, a feature which Win32 DLLs doesn't support. I then looked into MingW but having searched quite extensively I cannot find any definitive answers regarding the autotools and libtool support. I know there is some level of support, but how do you set up a system which can use the configure script and make the whole project, DLLs and all. Ideally I would like fully automatic support, i.e. just run ./configure and make all from the command line and it would build under mingw. I know I am asking a lot, but I thought someone here would know if this is a viable target or not. I am quite prepared to modify the Makefile.am and/or configure.in scripts to make this work, if it doesn;t affect existing build targets. Any help would be greatly appreciated. Cheers PaulG _______________________________________________ MinGW-users mailing list Min...@li... You may change your MinGW Account Options at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Paul G. <PGr...@su...> - 2001-10-30 17:41:06
|
The problems I am trying to overcome are actually with the compiler. There are a number of known issues with standards compliance and MSVC6. Up til now we have managed to get round them, but now the problems are at the point where we would have to make major changes to the sourcecode to overcome the lack of support, and we don't want to do that. The unresolved references I refer to are actually in the DLL, i.e. in Posix it is OK to link the DLL and have unresolved references to another library as long as this library is linked into the main executable which is responsible for loading the DLL. This way when the DLL is loaded and initialised any dangling references are resolved against the availed functions present in the executable, thus fixing any unresolved references. I really do want to use autotools if I can as this would make the build process the same irrespective of the target, and avoid the problems of keeping multiple configuration/project/workspace files up to date. I have seen mention of an autotools build for MingW, something to do with a self hosting installation. But can't find much information on using it. The self hosting installation I found mostly dates back to 1999, is this the latest? If so is it sufficiently up to date to be of use? To reiterate, what I would like, in an ideal world, is a build system the same as on Posix, using autotools but building for native Windows. Cheers PaulG > -----Original Message----- > From: Castro, Edison M. (USPC.PCT.Hopewell) > [mailto:ECastro@NA2.US.ML.com] > Sent: 30 October 2001 17:19 > To: 'min...@li...' > Subject: RE: [Mingw-users] Is MingW suitable for my needs. > > > Paul > > I am trying to understand exactly what is the problem you are > trying to > overcome. What are those deficiencies you speak of with Win32 > DLL and MS > compiler. > > Is it the fact that you would like to resolve unresolved > references at run > time?. There are two ways of doing this in WIN32. One is to > explicitly load > the DLL and ask for those entry point you require. The other > is by "demand > load" linking in which the DLL is only load if any entry > point of such DLL > is called as part of the execution of the program. > > Is it the fact that you want to use autotools?. I think there > is a version > of autotools compile for MINGW. > > |
From: Earnie B. <ear...@ya...> - 2001-10-30 18:31:10
|
I don't know if MinGW is suitable for your needs or not. A lot of people cross build for the Win32 using MinGW so they can have a POSIX platform for building purposes. I'm attempting to create a "native" POSIX build environment for MinGW. I've created a fork of the Cygwin-1.3.3 runtime to help accomplish this. I have announced a prerelease on the MinGW-Dvlpr list of the MSYS system but haven't yet announced it on this list. I've recently made it publicly available if you're willing to help test this. I don't have this fork anywhere near ready for real MinGW use but I do need testers for feedback. If I get enough response from this I'll setup a MinGW-msys email account for discussion. Earnie. Paul Gregory wrote: > > The problems I am trying to overcome are actually with the compiler. There > are a number of known issues with standards compliance and MSVC6. Up til now > we have managed to get round them, but now the problems are at the point > where we would have to make major changes to the sourcecode to overcome the > lack of support, and we don't want to do that. > > The unresolved references I refer to are actually in the DLL, i.e. in Posix > it is OK to link the DLL and have unresolved references to another library > as long as this library is linked into the main executable which is > responsible for loading the DLL. This way when the DLL is loaded and > initialised any dangling references are resolved against the availed > functions present in the executable, thus fixing any unresolved references. > > I really do want to use autotools if I can as this would make the build > process the same irrespective of the target, and avoid the problems of > keeping multiple configuration/project/workspace files up to date. > > I have seen mention of an autotools build for MingW, something to do with a > self hosting installation. But can't find much information on using it. The > self hosting installation I found mostly dates back to 1999, is this the > latest? If so is it sufficiently up to date to be of use? > > To reiterate, what I would like, in an ideal world, is a build system the > same as on Posix, using autotools but building for native Windows. > > Cheers > > PaulG > > > -----Original Message----- > > From: Castro, Edison M. (USPC.PCT.Hopewell) > > [mailto:ECastro@NA2.US.ML.com] > > Sent: 30 October 2001 17:19 > > To: 'min...@li...' > > Subject: RE: [Mingw-users] Is MingW suitable for my needs. > > > > > > Paul > > > > I am trying to understand exactly what is the problem you are > > trying to > > overcome. What are those deficiencies you speak of with Win32 > > DLL and MS > > compiler. > > > > Is it the fact that you would like to resolve unresolved > > references at run > > time?. There are two ways of doing this in WIN32. One is to > > explicitly load > > the DLL and ask for those entry point you require. The other > > is by "demand > > load" linking in which the DLL is only load if any entry > > point of such DLL > > is called as part of the execution of the program. > > > > Is it the fact that you want to use autotools?. I think there > > is a version > > of autotools compile for MINGW. > > > > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > https://lists.sourceforge.net/lists/listinfo/mingw-users -- Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Dmitry B. <db...@ma...> - 2001-10-30 19:12:24
|
Earnie Boyd <ear...@ya...> writes: > I don't know if MinGW is suitable for your needs or not. A lot of > people cross build for the Win32 using MinGW so they can have a POSIX > platform for building purposes. I'm attempting to create a "native" > POSIX build environment for MinGW. I've created a fork of the > Cygwin-1.3.3 runtime to help accomplish this. I still fail to understand why Cygwin and its gcc with -mno-cygwin is not enough. Too much space on the disk? Or what? Why fork their code? Hope to hear from you soon, Dmitry |
From: Earnie B. <ear...@ya...> - 2001-10-31 13:23:57
|
Dmitry Bely wrote: > > Earnie Boyd <ear...@ya...> writes: > > > I don't know if MinGW is suitable for your needs or not. A lot of > > people cross build for the Win32 using MinGW so they can have a POSIX > > platform for building purposes. I'm attempting to create a "native" > > POSIX build environment for MinGW. I've created a fork of the > > Cygwin-1.3.3 runtime to help accomplish this. > > I still fail to understand why Cygwin and its gcc with -mno-cygwin is not > enough. Too much space on the disk? Or what? Why fork their code? > My goal is a Win32 POSIX environment for users of MinGW. It's just that I'm using a fork of Cygwin to accomplish that goal. MSYS will be client concentric not dealing with server issues. MSYS will require no fussing with /etc/password or /etc/group files. MSYS will not use the MS Registry for controlling "mount points" MSYS will handle binary vs text in an automagical method. MSYS will ... Here is the text from /msys/1.0/doc/MSYS/MSYS_VS_CYGWIN: ------------------------------------------------------------------------------ mount: The mount command is only used to display all mount points. The mount points for the very important are automounted. Nothing is stored in the Win32 registry database. If you wish to add other mount points, ones that aren't auto mounted, then you may do so in the /etc/fstab file. i ROOTPATH "/": The "/" auto mount point is currently a reference to the parent directory of the directory containing the msys-1.0.dll file. In later releases the / will be a reference to a pseudo device that points to the mount points. I.E. in a later release it is planned that `ls /' will list the mount points. /bin: The /bin auto mount point is a reference to the directory containing the msys-1.0.dll file. I.E. if the path to msys-1.0.dll is C:\msys\1.0\bin\msys-1.0.dll then /bin resolves to C:\msys\1.0\bin. /tmp: The /tmp auto mount point is a reference to the directory that is referenced by the Win32 TMP environment variable. I.E. if the win32 TMP environment variable value is C:\TEMP then the /tmp mount point resolves to C:\TEMP. /usr: The /usr auto mount point is a reference to the parent directory of the directory containing the msys-1.0.dll file. I.E. if the path to msys-1.0.dll is C:\msys\1.0\bin\msys-1.0.dll then the /usr mount point resolves to C:\msys\1.0. /cygdrive: There is no such item. All devices and mapped shares are auto mounted with the device letter as the mount point. E.G.: the C:\ drive is referenced as /c. /etc/fstab: If this file exists then it is read for user specified mount points. The form of the record is [PHYSICAL PATH][WHITE SPACE][MOUNT POINT] where [WHITE SPACE] is one or more spaces and/or tabs. Currently no comments are allowed in the file. binary vs text: File processing mode is set to binary. This is not changeable. I had originally planned to set this to text mode processing but ran into various problems of which volumes have been written in the Cygwin archives. For release 1.0 of MSYS this means that you cannot have \r\n line endings on text files. In a future release it is planned to "Do The Right Thing" and predetermine the type of file being opened and set text or binary processing as appropriate for reading files. Or, predetermine the type of file and as the file is being read remove the \r from the end of the line. uname -s: The default system name is returned as MSYS_NT-4.0, if you're on NT 4.0. However you could export MSYSTEM=MINGW32 as change the returned value for `uname -s' to MINGW32_NT-4.0. This is done to aid the use of MSYS with MinGW and configuration scripts will determine that it is a MINGW32 build system. gcc: New switches -mmsys, -mmingw and -mcygwin cause searching in the appropriate include and lib directories, -mmsys is the default. Headers are located in /usr/include/msys, /usr/include/mingw and /usr/include/cygwin. Libraries are stored in /usr/lib/msys, /usr/lib/mingw and /usr/lib/cygwin. configure: I've a script to aid in configuring for differing systems named msysconfigure. To use it you simply `msysconfigure </path/to/src> <system>' where </path/to/src> is replaced with the path to the configure script and <system> is replaced with one of msys, mingw or cygwin, lower case. See MSYSCONFIGURE for more documentation. -- Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Dmitry B. <db...@ma...> - 2001-10-31 14:52:20
|
Earnie Boyd <ear...@ya...> writes: > > > I don't know if MinGW is suitable for your needs or not. A lot of > > > people cross build for the Win32 using MinGW so they can have a POSIX > > > platform for building purposes. I'm attempting to create a "native" > > > POSIX build environment for MinGW. I've created a fork of the > > > Cygwin-1.3.3 runtime to help accomplish this. > > > > I still fail to understand why Cygwin and its gcc with -mno-cygwin is not > > enough. Too much space on the disk? Or what? Why fork their code? > > > > My goal is a Win32 POSIX environment for users of MinGW. It's already exists and it's name is Cygwin. > It's just that > I'm using a fork of Cygwin to accomplish that goal. MSYS will be client > concentric not dealing with server issues. MSYS will require no fussing > with /etc/password or /etc/group files. Default Cygwin settings for them are OK. > MSYS will not use the MS > Registry for controlling "mount points" It can be hardly considered as an advantage. > MSYS will handle binary vs text > in an automagical method. Simply not possible. The only "automation" you can implement is binary-only mounting. > MSYS will ... > > Here is the text from /msys/1.0/doc/MSYS/MSYS_VS_CYGWIN: > ------------------------------------------------------------------------------ > mount: The mount command is only used to display all mount points. The > mount > points for the very important are automounted. Nothing is stored in the > Win32 > registry database. If you wish to add other mount points, ones that > aren't > auto mounted, then you may do so in the /etc/fstab file. i > > ROOTPATH "/": The "/" auto mount point is currently a reference to the > parent > directory of the directory containing the msys-1.0.dll file. In later > releases > the / will be a reference to a pseudo device that points to the mount > points. Where are you going to store it, if Registry is taboo for you? > I.E. in a later release it is planned that `ls /' will list the mount > points. I don't like all this black magic. Cygwin's way of handling mounts seems to be more logical and more flexible. > /bin: The /bin auto mount point is a reference to the directory > containing the > msys-1.0.dll file. I.E. if the path to msys-1.0.dll is > C:\msys\1.0\bin\msys-1.0.dll then /bin resolves to C:\msys\1.0\bin. > > /tmp: The /tmp auto mount point is a reference to the directory that is > referenced by the Win32 TMP environment variable. I.E. if the win32 TMP > environment variable value is C:\TEMP then the /tmp mount point resolves > to > C:\TEMP. > > /usr: The /usr auto mount point is a reference to the parent directory > of the > directory containing the msys-1.0.dll file. I.E. if the path to > msys-1.0.dll > is C:\msys\1.0\bin\msys-1.0.dll then the /usr mount point resolves to > C:\msys\1.0. > > /cygdrive: There is no such item. All devices and mapped shares are > auto > mounted with the device letter as the mount point. E.G.: the C:\ drive > is > referenced as /c. It means that you cannot have "c" or "d" directory in the root. I don't think that's good. > /etc/fstab: If this file exists then it is read for user specified > mount > points. The form of the record is [PHYSICAL PATH][WHITE SPACE][MOUNT > POINT] > where [WHITE SPACE] is one or more spaces and/or tabs. Currently no > comments > are allowed in the file. > > binary vs text: File processing mode is set to binary. This is not > changeable. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ You wrote above: > MSYS will handle binary vs text > in an automagical method. I should say it's good "automagical method" :-)) If you are going to treat all files as binary, how will you perform <CR><LF> -> <LF> translation? Suppose, you are editing <CR><LF> delimited file with POSIX application that knows nothing about <CR>s. In that case you will get the file some lines will be terminated with <LF>s, and some with <CR><LF>s. Again, your approach is not flexible. Cygwin developers invented text mounts because they are really necessary sometimes. BTW, all Cygwin mounts are binary by default. > I had originally planned to set this to text mode processing but ran > into > various problems of which volumes have been written in the Cygwin > archives. > For release 1.0 of MSYS this means that you cannot have \r\n line > endings on > text files. In a future release it is planned to "Do The Right Thing" > and > predetermine the type of file being opened and set text or binary > processing > as appropriate for reading files. Or, predetermine the type of file and > as the > file is being read remove the \r from the end of the line. > > uname -s: The default system name is returned as MSYS_NT-4.0, if you're > on > NT 4.0. However you could export MSYSTEM=MINGW32 as change the returned > value > for `uname -s' to MINGW32_NT-4.0. This is done to aid the use of MSYS > with > MinGW and configuration scripts will determine that it is a MINGW32 > build > system. > > gcc: New switches -mmsys, -mmingw and -mcygwin cause searching in the > appropriate include and lib directories, -mmsys is the default. Can be easily integrated into Cygwin. > Headers > are > located in /usr/include/msys, /usr/include/mingw and > /usr/include/cygwin. > Libraries are stored in /usr/lib/msys, /usr/lib/mingw and > /usr/lib/cygwin. No principal difference with current Cygwin layout. > configure: I've a script to aid in configuring for differing systems > named > msysconfigure. To use it you simply `msysconfigure </path/to/src> > <system>' > where </path/to/src> is replaced with the path to the configure script > and > <system> is replaced with one of msys, mingw or cygwin, lower case. See > MSYSCONFIGURE for more documentation. Again, can be integrated into Cygwin. To summarize, I see no reason for forking Cygwin code. And I understand why Cygwin developers are not happy with that. Hope to hear from you soon, Dmitry |
From: Earnie B. <ear...@ya...> - 2001-10-31 15:43:40
|
Dmitry Bely wrote: > > > I don't like all this black magic. Cygwin's way of handling mounts seems to > be more logical and more flexible. > I know that MSYS won't fit everyone's needs. Cygwin is a fine tool and I doubt that I'll quit using it. Cygwin isn't for everyone, it doesn't fit everyone's needs. > > /cygdrive: There is no such item. All devices and mapped shares are > > auto > > mounted with the device letter as the mount point. E.G.: the C:\ drive > > is > > referenced as /c. > > It means that you cannot have "c" or "d" directory in the root. I don't > think that's good. > Why not? /c/c/whatever works. > > /etc/fstab: If this file exists then it is read for user specified > > mount > > points. The form of the record is [PHYSICAL PATH][WHITE SPACE][MOUNT > > POINT] > > where [WHITE SPACE] is one or more spaces and/or tabs. Currently no > > comments > > are allowed in the file. > > > > binary vs text: File processing mode is set to binary. This is not > > changeable. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^^^^^ > > You wrote above: > > > MSYS will handle binary vs text > > in an automagical method. > > I should say it's good "automagical method" :-)) > > If you are going to treat all files as binary, how will you perform > <CR><LF> -> <LF> translation? Suppose, you are editing <CR><LF> delimited > file with POSIX application that knows nothing about <CR>s. In that case > you will get the file some lines will be terminated with <LF>s, and some > with <CR><LF>s. > That is planned. It isn't coded yet. > Again, your approach is not flexible. Cygwin developers invented text mounts > because they are really necessary sometimes. BTW, all Cygwin mounts are > binary by default. > You don't know Cygwin very well. ;T I don't really care for flexibility in this matter of DOS<->UNIX line ending formats for MSYS. I do understand your need for flexibility, however it's not my desire for MSYS. > > I had originally planned to set this to text mode processing but ran > > into > > various problems of which volumes have been written in the Cygwin > > archives. > > For release 1.0 of MSYS this means that you cannot have \r\n line > > endings on > > text files. In a future release it is planned to "Do The Right Thing" > > and > > predetermine the type of file being opened and set text or binary > > processing > > as appropriate for reading files. Or, predetermine the type of file and > > as the > > file is being read remove the \r from the end of the line. > > > > uname -s: The default system name is returned as MSYS_NT-4.0, if you're > > on > > NT 4.0. However you could export MSYSTEM=MINGW32 as change the returned > > value > > for `uname -s' to MINGW32_NT-4.0. This is done to aid the use of MSYS > > with > > MinGW and configuration scripts will determine that it is a MINGW32 > > build > > system. > > > > gcc: New switches -mmsys, -mmingw and -mcygwin cause searching in the > > appropriate include and lib directories, -mmsys is the default. > > Can be easily integrated into Cygwin. > Agreed. > > Headers > > are > > located in /usr/include/msys, /usr/include/mingw and > > /usr/include/cygwin. > > Libraries are stored in /usr/lib/msys, /usr/lib/mingw and > > /usr/lib/cygwin. > > No principal difference with current Cygwin layout. > Agreed. > > configure: I've a script to aid in configuring for differing systems > > named > > msysconfigure. To use it you simply `msysconfigure </path/to/src> > > <system>' > > where </path/to/src> is replaced with the path to the configure script > > and > > <system> is replaced with one of msys, mingw or cygwin, lower case. See > > MSYSCONFIGURE for more documentation. > > Again, can be integrated into Cygwin. > > To summarize, I see no reason for forking Cygwin code. And I understand > why Cygwin developers are not happy with that. > I realize that what I've changed thus far could be "incorporated" into Cygwin. The coding I've done thus far could be merged into the Cygwin code base without detriment to the Cygwin code. However, an internal fork is just as much a fork as an external fork. It may be possible that this fork will eventually be merged back into the Cygwin code base. But, I want to develop it externally. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Dmitry B. <db...@ma...> - 2001-11-01 09:02:43
|
Earnie Boyd <ear...@ya...> writes: > > I don't like all this black magic. Cygwin's way of handling mounts seems to > > be more logical and more flexible. > > I know that MSYS won't fit everyone's needs. Cygwin is a fine tool and > I doubt that I'll quit using it. Cygwin isn't for everyone, it doesn't > fit everyone's needs. I am just trying to understand which your needs it does not fit? Maybe you don't like that Cygwin development is controlled by somebody else? Why to invent new semi-POSIX environment? > > > /cygdrive: There is no such item. All devices and mapped shares are > > > auto > > > mounted with the device letter as the mount point. E.G.: the C:\ drive > > > is > > > referenced as /c. > > > > It means that you cannot have "c" or "d" directory in the root. I don't > > think that's good. > > > > Why not? /c/c/whatever works. Yes, but "mkdir /c" does not. Choosing "/cygdrive" as a disk mount prefix is logical: many people have / mounted to "C:\" which in turn can easily have "C:\c" subdirectory ... > > > /etc/fstab: If this file exists then it is read for user specified > > > mount > > > points. The form of the record is [PHYSICAL PATH][WHITE SPACE][MOUNT > > > POINT] > > > where [WHITE SPACE] is one or more spaces and/or tabs. Currently no > > > comments > > > are allowed in the file. > > > > > > binary vs text: File processing mode is set to binary. This is not > > > changeable. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ^^^^^^^^^^ > > > > You wrote above: > > > > > MSYS will handle binary vs text > > > in an automagical method. > > > > I should say it's good "automagical method" :-)) > > > > If you are going to treat all files as binary, how will you perform > > <CR><LF> -> <LF> translation? Suppose, you are editing <CR><LF> delimited > > file with POSIX application that knows nothing about <CR>s. In that case > > you will get the file some lines will be terminated with <LF>s, and some > > with <CR><LF>s. > > > > That is planned. It isn't coded yet. How are you going to choose automatically between binary and text mode while performing open()? Just an idea please, if possible. > > Again, your approach is not flexible. Cygwin developers invented text mounts > > because they are really necessary sometimes. BTW, all Cygwin mounts are > > binary by default. > > > > You don't know Cygwin very well. ;T Very likely. Please correct me if I was wrong somethere (BTW, where?) > I don't really care for flexibility > in this matter of DOS<->UNIX line ending formats for MSYS. I do > understand your need for flexibility, however it's not my desire for > MSYS. Does this mean that you will patch all utilities, taken from the real POSIX? [...] > > Again, can be integrated into Cygwin. > > > > To summarize, I see no reason for forking Cygwin code. And I understand > > why Cygwin developers are not happy with that. > > > > I realize that what I've changed thus far could be "incorporated" into > Cygwin. The coding I've done thus far could be merged into the Cygwin > code base without detriment to the Cygwin code. However, an internal > fork is just as much a fork as an external fork. It may be possible > that this fork will eventually be merged back into the Cygwin code > base. But, I want to develop it externally. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ OK, that's the reason. I just hope that MinGW libraries/headers included into Cygwin will also be updated from time to time :-) Hope to hear from you soon, Dmitry |
From: Christopher F. <cg...@re...> - 2001-11-03 04:06:28
|
On Thu, Nov 01, 2001 at 11:59:36AM +0300, Dmitry Bely wrote: >OK, that's the reason. I just hope that MinGW libraries/headers included >into Cygwin will also be updated from time to time :-) I can guarantee this will happen, one way or the other. cgf |
From: Tor L. <tm...@ik...> - 2001-10-30 21:38:46
|
Paul Gregory writes: > The unresolved references I refer to are actually in the DLL, i.e. in Posix > it is OK to link the DLL and have unresolved references to another library > as long as this library is linked into the main executable which is > responsible for loading the DLL. Umm. Do I understand you correctly: You have one DLL, libA. You have another DLL, libB, which wants to use a function from libA. You have an executable, prog, which (at least) calls functions from libB. Does it also call functions from libA? Anyway, I don't see why you don't simly link libB with libA's import library? Even if the executable also imports from libA, this doesn't mean that libA would be duplicated or anything, if that is what you are afraid of? Or is libA a static library? Then do as below, use a .def file to generate an import library for the EXE. (Do not link libA into libB. If you do that, prog.exe and libB.dll get separate copies which can cause all kinds of fun. But you probably knew that.) > This way when the DLL is loaded and initialised any dangling > references are resolved against the availed functions present in > the executable, thus fixing any unresolved references. Or are you saying that you want to call functions in the executable from the DLL? That is not a problem either. You mark those function for export in the executable (either using __declspec(dllexport) or a .def file, maybe even both are necessary with gcc), and generate an import library for the executable. Then link the DLL with that import library. (Yes, this does sound like a circular dependency, but remember that if you have a .def file, you can generate an import library even if the DLL (or EXE) that exports the entry points doesn't (yet) exist.) To build an executable with exported functions you cannot use a simple gcc invokation like that which is used to generate a DLL. You must first generate an .exp file with dlltool, and link that in when building the EXE. For an example of this being used with autotools and libtool, see glib-1.3.10's gmodule directory, the gmoduletest program. (It doesn't need to use the import library for an EXE trick, as the DLL looks up an exported symbol (that is in the EXE) dynamically.) --tml |
From: Benjamin R. <Ben...@ep...> - 2001-11-02 21:57:49
|
Hi Tor, Tor Lillqvist <tm...@ik...> writes: > Or are you saying that you want to call functions in the executable > from the DLL? That is not a problem either. You mark those function > for export in the executable (either using __declspec(dllexport) or > a .def file, maybe even both are necessary with gcc), and generate > an import library for the executable. Then link the DLL with that > import library. Have you done that? My memory may be failing me, but I think that this doesn't work. Executables can not be linked to via an import library on Windows. Of course that problem can always be solved with a function pointer and some additional code, which also has the side effect of being better code (IMHO ;-). so long, benny |
From: Tor L. <tm...@ik...> - 2001-11-02 22:30:08
|
> > Or are you saying that you want to call functions in the executable > > from the DLL? That is not a problem either. You mark those function > > for export in the executable (either using __declspec(dllexport) or > > a .def file, maybe even both are necessary with gcc), and generate > > an import library for the executable. Then link the DLL with that > > import library. > > Have you done that? My memory may be failing me, but I think that > this doesn't work. Executables can not be linked to via an import > library on Windows. You can use an import library for an executable when linking a DLL, but then the DLL will only work when loaded by *that* executable. (This is the case for instance with GIMP "modules", which are DLLs that are used by the GIMP, and presumably even can't be used by other exes, as they import functions from gimp.exe.) > Of course that problem can always be solved with a function pointer > and some additional code, which also has the side effect of being > better code (IMHO ;-). Yes, g_module_symbol for Win32 does that. It first tries GetProcAddress (GetModuleHandle (NULL), symbol_name) which looks for the symbol in the .EXE, then enumerates the "modules" currently loaded (DLLs) using either the Toolhelp or PSAPI APIs and looks for the symbol in each module. --tml |
From: Benjamin R. <Ben...@ep...> - 2001-11-02 23:27:02
|
Hi Tor, Tor Lillqvist <tm...@ik...> writes: > You can use an import library for an executable when linking a DLL, > but then the DLL will only work when loaded by *that* > executable. (This is the case for instance with GIMP "modules", > which are DLLs that are used by the GIMP, and presumably even can't > be used by other exes, as they import functions from gimp.exe.) I see. I thought this doesn't work at all. > > Of course that problem can always be solved with a function pointer > > and some additional code, which also has the side effect of being > > better code (IMHO ;-). > > Yes, g_module_symbol for Win32 does that. It first tries > GetProcAddress (GetModuleHandle (NULL), symbol_name) which looks for > the symbol in the .EXE, then enumerates the "modules" currently loaded > (DLLs) using either the Toolhelp or PSAPI APIs and looks for the > symbol in each module. That was certainly not what I meant ;-). It seems amazing to me, though, what tricks people play for a little bit of convenience that they are used to. so long, benny |
From: Earnie B. <ear...@ya...> - 2001-11-01 13:12:42
|
Dmitry Bely wrote: > > Earnie Boyd <ear...@ya...> writes: > > > > > > > It means that you cannot have "c" or "d" directory in the root. I don't > > > think that's good. > > > > > > > Why not? /c/c/whatever works. > > Yes, but "mkdir /c" does not. Choosing "/cygdrive" as a disk mount prefix is > logical: many people have / mounted to "C:\" which in turn can easily have > "C:\c" subdirectory ... > Yes `mkdir /c' works just as equally well, however you get the "cannot create directory" error. This argument ain't going to get very far. If you want to create a directory C:\C\ and use MSYS to create that directory you would 'mkdir /c/c'. > > > > > > If you are going to treat all files as binary, how will you perform > > > <CR><LF> -> <LF> translation? Suppose, you are editing <CR><LF> delimited > > > file with POSIX application that knows nothing about <CR>s. In that case > > > you will get the file some lines will be terminated with <LF>s, and some > > > with <CR><LF>s. > > > > > > > That is planned. It isn't coded yet. > > How are you going to choose automatically between binary and text mode > while performing open()? Just an idea please, if possible. > I don't know yet. I've given it some thought but haven't researched it enough yet. One thought is to read a block of say 1024 bytes and if I find a \r\n combination more than once set the read to text mode. The other thought is to just translate \r\n to \n\0 in the read function. > > > Again, your approach is not flexible. Cygwin developers invented text mounts > > > because they are really necessary sometimes. BTW, all Cygwin mounts are > > > binary by default. > > > > > > > You don't know Cygwin very well. ;T > > Very likely. Please correct me if I was wrong somethere (BTW, where?) > Cygwin's default mode is text mode. You have to specifically tell it to use binary mode. However, setup.exe defaults to mounting in binary mode. If you reference a file that has no pathed reference in the mount entries (e.g.: //foo/bar/baz.txt) then Cygwin will open it in text mode. > > I don't really care for flexibility > > in this matter of DOS<->UNIX line ending formats for MSYS. I do > > understand your need for flexibility, however it's not my desire for > > MSYS. > > Does this mean that you will patch all utilities, taken from the real > POSIX? > No, I plan the translation in MSYS as discussed above. > [...] > > > > Again, can be integrated into Cygwin. > > > > > > To summarize, I see no reason for forking Cygwin code. And I understand > > > why Cygwin developers are not happy with that. > > > > > > > I realize that what I've changed thus far could be "incorporated" into > > Cygwin. The coding I've done thus far could be merged into the Cygwin > > code base without detriment to the Cygwin code. However, an internal > > fork is just as much a fork as an external fork. It may be possible > > that this fork will eventually be merged back into the Cygwin code > > base. But, I want to develop it externally. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > OK, that's the reason. I just hope that MinGW libraries/headers included > into Cygwin will also be updated from time to time :-) > Glad we have that settled. :^) -- Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Paul G. <pga...@qw...> - 2001-10-31 03:17:56
|
Hi folks, On 30 Oct 2001 at 16:26, the Illustrious Paul Gregory wrote: > Hi all, > I am involved in an Open Source project which is primarily Posix > based. It uses Automake/Autoconf/libtool for its configuration > management. Don't know if it matters what OS you are using. Do know that if you have NT4 system that Posix compatibility is included as a subsystem, in much the same way that OS2 is a subsystem. The limitation of using the NT4 Posix subsystem only lies in whether or not you have installed the NT4 Resource Kit (Workstation/Server). Using the Posix subsystem, you can address, at the very least, directory limitations of MS Kernel/Shell processing. Cobbling Software: Some years ago I did manage to generate a functional autoconfig/automake support system (for Mingw32 or Mingw gcc-2.95.2) for the NT4 system (msvcrt) with the Posix Subsystem enabled. Now I would have to recreate the whole process from scratch, but at least it might offer you a place to start. The (Unix) shell scripts that are typically assumed for automake/autoconf implementations, require some sort of win32 (non-cygwin1 based shells are available.) substitutions. Win32 .bat files can, in principle, reproduce (again, in principle) similar Unix shell commands. However, such a thing would involve writing a specific .bat process customized for your Win32 application. There is an example of such a cobbling of software available if you take a look at the very outdated Mingw port for Mesa 3D. In principle, autoconf/automake are nothing more than script processing utilities. A Win32 .bat file can act as a sort of Win32 ./config source. > I then looked into MingW but having searched quite extensively I > cannot find any definitive answers regarding the autotools and libtool > support. I know there is some level of support, but how do you set up a > system which can use the configure script and make the whole project, > DLLs and all. Without a shell such as ash/bash/csh, you can't use a configure script (./configure) unless you convert that configure script to a .bat script or implement a win32 emulated Unix shell. > Ideally I would like fully automatic support, i.e. just > run ./configure and make all from the command line and it would build > under mingw. PW32 might have some support for this. > I know I am asking a lot, but I thought someone here would > know if this is a viable target or not. I am quite prepared to modify > the Makefile.am and/or configure.in scripts to make this work, if it > doesn;t affect existing build targets. I can say "yes, it is "viable". It's just not simple. Earnies' MSYS would be a good choice once he feels it is ready. There are means (currently) of substituting existing Windows Shell processes (cmd.exe/command.exe) for existing Unix Shell utilities. libtool has been ported for Mingw. Paul G. > > Any help would be greatly appreciated. > > > Cheers > > PaulG > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Nothing real can be threatened. Nothing unreal exists. |
From: Paul G. <PGr...@su...> - 2001-10-31 13:38:12
|
Sounds like MSYS is the sort of thing I need, I will look into it further. Cheers PaulG > > My goal is a Win32 POSIX environment for users of MinGW. > It's just that > I'm using a fork of Cygwin to accomplish that goal. MSYS > will be client > concentric not dealing with server issues. MSYS will require > no fussing > with /etc/password or /etc/group files. MSYS will not use the MS > Registry for controlling "mount points" MSYS will handle > binary vs text > in an automagical method. MSYS will ... > . . . > > -- > Earnie. > |