From: Kirk J. <kir...@gm...> - 2013-06-24 19:39:06
|
For what it's worth, and as a complete n00b who probably should keep my mouth shut, I like Keith's method for two reasons 1. It allows the user to _understand_ what's going on behind the scenes, rather than blindly putting files in a default directory. 2. It seems awfully annoying to have to always make sure third party packages install into the MinGW/lib and /include directories, particularly because running pre-packaged configure scripts from within MSYS will put the files in "standard Linux" locations with respect to the MSYS root. It makes sense to me to think of the MSYS file system as an effective Linux file system and simply tell gcc that you're doing so. In Keith's case, by editing the specs file. If I'm way off my head please feel free to slap me down :) |
From: Keith M. <kei...@us...> - 2013-06-24 19:49:32
|
On 24/06/13 20:39, Kirk Joppy wrote: > 2. It seems awfully annoying to have to always make sure third party > packages install into the MinGW/lib and /include directories, > particularly because running pre-packaged configure scripts from > within MSYS will put the files in "standard Linux" locations with > respect to the MSYS root. Then you're not configuring them correctly; you should be specifying the --prefix option, to put them in an appropriate MinGW location. -- Regards, Keith. |
From: Kirk J. <kir...@gm...> - 2013-06-24 19:55:24
|
> Then you're not configuring them correctly; you should be specifying the > --prefix option, to put them in an appropriate MinGW location. I feel like I'm getting conflicting information here. My understanding was that you can either 1. Install things into /MinGW. This puts dependencies in default search paths and makes your life easy. 2. Install things wherever you want and tell the compiler where to find them (in your case by editing specs). What am I missing? |
From: Keith M. <kei...@us...> - 2013-06-24 20:22:06
|
On 24/06/13 20:55, Kirk Joppy wrote: >> Then you're not configuring them correctly; you should be specifying the >> --prefix option, to put them in an appropriate MinGW location. > > I feel like I'm getting conflicting information here. My understanding > was that you can either > > 1. Install things into /MinGW. This puts dependencies in default > search paths and makes your life easy. > 2. Install things wherever you want and tell the compiler where to > find them (in your case by editing specs). > > What am I missing? Option #2 of the IncludePathHOWTO: install supplementary libraries and their headers into /mingw-local, or some such, which doesn't get blown away, when you decide to purge and reinstall your /mingw tree. IMO, option #1 is too vulnerable; option #3, (which is your #2 above), is too much of a faff, with too many intrusions in specs, (although the technique I illustrated in the patch I offered yesterday makes that somewhat more manageable than the directly in-place modifications you said you had made). My option #2 is the middle road, with only one -I and one -L addition to specs, and is more consistent with common practice on Linux, where /usr/local is the equivalent of /mingw-local, (or /mingw/local if you prefer, and can take care not to blow it away with the rest of /mingw when you really meant to keep it). -- Regards, Keith. |
From: Kirk J. <kir...@gm...> - 2013-06-24 20:38:26
|
> Option #2 of the IncludePathHOWTO: install supplementary libraries and > their headers into /mingw-local, or some such, which doesn't get blown > away, when you decide to purge and reinstall your /mingw tree. Oh, ok we just crossed communication wires. I missed that you were talking about eg. /mingw/local, a user made directory. By the way, despite the fact that I installed wxWidgets into the MSYS file system under /local/lib and /local/include, my project's configure now finds it no problem. I don't understand that one, but I won't worry about it for now. I can now get through configure on my project, but make fails due to '_tcsclen' was not declared in this scope. While this looks like a source code error I'm surprised because I gather from online sources that this has something to do with tchar, a standard windows library. Is that not included in mingw? |
From: Keith M. <kei...@us...> - 2013-06-24 20:56:11
|
On 24/06/13 21:38, Kirk Joppy wrote: > I can now get through configure on my project, but make fails due to > '_tcsclen' was not declared in this scope. While this looks like a > source code error I'm surprised because I gather from online sources > that this has something to do with tchar, a standard windows library. > Is that not included in mingw? _tcslen *is* declared, in MinGW's tchar.h; _tcsclen appears not to be. According to MSDN, the two are equivalent in all but the _MBCS defined case. Patches to add _tcsclen, (with appropriate ChangeLog), will be welcome. -- Regards, Keith. |
From: Kirk J. <kir...@gm...> - 2013-06-24 21:19:46
|
> _tcslen *is* declared, in MinGW's tchar.h; _tcsclen appears not to be. > According to MSDN, the two are equivalent in all but the _MBCS defined > case. Patches to add _tcsclen, (with appropriate ChangeLog), will be > welcome. Thank you. I would be happy to contribute and will try my best to do a good job. I started learning C++ about a month ago so I warn you that code I write at this point might contain silly errors that experienced users wouldn't make. |
From: Keith M. <kei...@us...> - 2013-06-25 06:55:26
|
On 24/06/13 22:19, Kirk Joppy wrote: >> _tcslen *is* declared, in MinGW's tchar.h; _tcsclen appears not to be. >> According to MSDN, the two are equivalent in all but the _MBCS defined >> case. Patches to add _tcsclen, (with appropriate ChangeLog), will be >> welcome. > > Thank you. I would be happy to contribute and will try my best to do a > good job. I started learning C++ about a month ago so I warn you that > code I write at this point might contain silly errors that experienced > users wouldn't make. An appropriate implementation shouldn't be C++, specifically; it needs to work for plain C too. From a cursory glance at MSDN[1], _tcsclen is an alias for strlen(), wcslen(), or _mbslen(), depending on the defined states of _MBCS and _UNICODE; it should be appropriately defined in tchar.h. [1] http://msdn.microsoft.com/en-us/library/78zh94ax%28v=vs.71%29.aspx -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2013-06-25 11:24:56
|
On Tue, Jun 25, 2013 at 2:55 AM, Keith Marshall wrote: > On 24/06/13 22:19, Kirk Joppy wrote: >>> _tcslen *is* declared, in MinGW's tchar.h; _tcsclen appears not to be. >>> According to MSDN, the two are equivalent in all but the _MBCS defined >>> case. Patches to add _tcsclen, (with appropriate ChangeLog), will be >>> welcome. >> >> Thank you. I would be happy to contribute and will try my best to do a >> good job. I started learning C++ about a month ago so I warn you that >> code I write at this point might contain silly errors that experienced >> users wouldn't make. > > An appropriate implementation shouldn't be C++, specifically; it needs > to work for plain C too. From a cursory glance at MSDN[1], _tcsclen is > an alias for strlen(), wcslen(), or _mbslen(), depending on the defined > states of _MBCS and _UNICODE; it should be appropriately defined in tchar.h. > > [1] http://msdn.microsoft.com/en-us/library/78zh94ax%28v=vs.71%29.aspx I've opened ticket https://sourceforge.net/p/mingw/bugs/1995/ for this. I'll resolve this for the up and coming 4.0 release. -- Earnie -- https://sites.google.com/site/earnieboyd |