From: Werner S. <sm...@ia...> - 2006-08-29 16:59:25
Attachments:
plplot_freetype.patch
|
Hi, in order to make plplot run with the freetype library on win32, some changes need to be done (patch attached): cmake/modules/freetype.cmake: WINDOWS/windows is not defined, therefore even on win32 it never jumps into this parts of the cmake file. This has to be replaced with WIN32 cmake/modules/wingcc.cmake: added freetype includes/library (copied from wxwidgets.cmake) src/plfreetype.c: visual c++ has a problem with the definition of access(). Also MINGW was not defined for my MinGW compiler. Therefore I changed the #ifdef to make it also clearer for the programmer: #if !defined(WIN32) || defined(__GNUC__) #include <unistd.h> #else #define F_OK 1 #include <stdio.h> int access( char *filename, int flag ) { so if we DON'T have WIN32 defined or __GNUC__ is defined (as is the case for MinGW) we use unistd.h, otherwise we define access(). I tested this patch for Visual C++ and MinGW for the wingcc and wxwidgets driver and it worked. This patch should have no effect on any other platform. Here are the cookbooks. You need to set the path to find the library and CMAKE_INCLUDE_PATH so that cmake finds the include files. Mind, you also need ming32-make for the Viusal C++ build!!! MinGW: * download and unzip freetype 2.2.1 (ft221.zip) * mingw32-make (compiler is detected) * mingw32-make (to compile the library) * copy objs\freetype.a objs\libfreetype.a * set FREETYPEDIR=C:\DevZone\freetype-2.2.1 * set PATH=%FREETYPEDIR%\objs;%PATH% * set CMAKE_INCLUDE_PATH=%FREETYPEDIR%\include * run cmake with your options Visual C++ 2005 * download and unzip freetype 2.2.1 (ft221.zip) * change line 69 of freetype-2.2.1\builds\compiler\visualc.mk to CFLAGS ?= /nologo /c /Ox /W3 /WX /D_CRT_SECURE_NO_DEPRECATE otherwise it stops the build because of warnings (/WX) since it doesn't know the /G5 option (this may not be necessary for Visual C++ 6.0 and/or 2003 * path_to_gnu_make\mingw32-make setup visualc * path_to_gnu_make\mingw32-make * set FREETYPEDIR=C:\DevZone\freetype-2.2.1 * set PATH=%FREETYPEDIR%\objs;%PATH% * set CMAKE_INCLUDE_PATH=%FREETYPEDIR%\include * run cmake with your options Please apply the patch if you think it's okay. Regards, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2006-08-29 20:13:34
|
On 2006-08-29 17:51+0200 Werner Smekal wrote: > Hi, > > in order to make plplot run with the freetype library on win32, some changes > need to be done (patch attached): > [...] Also MINGW was not > defined for my MinGW compiler. [....] I don't think it will ever be defined. I confirmed that MINGW was only used in that one place in our source code that you corrected. > Therefore I changed the #ifdef [...] > so if we DON'T have WIN32 defined or __GNUC__ is defined (as is the case for > MinGW) we use unistd.h, otherwise we define access(). > > I tested this patch for Visual C++ and MinGW for the wingcc and wxwidgets > driver and it worked. This patch should have no effect on any other platform. That patch looked fine to me. Also I double-checked with a quick Linux build test that it had no bad effect in that case. Therefore, I have applied it to cvs. > > Here are the cookbooks [for dealing with freetype2 on windows] Just now I have committed a change to the INSTALL file to put in a whole new section concerned with our CBS. I have put in Unix instructions there and also Werner's cookbooks for accessing freetype2 on windows. However, we also need overall windows instructions for our CBS. Arjen, could you supply those please? Thanks, Werner, for your work actuating plfreetype on windows. I assume that makes the wingcc results look a lot better. That work should also make the gd-related device results look a lot better once you or Arjen get those devices working on windows. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-08-30 06:32:28
|
Alan W. Irwin wrote: >Just now I have committed a change to the INSTALL file to put in a whole new >section concerned with our CBS. I have put in Unix instructions there and >also Werner's cookbooks for accessing freetype2 on windows. However, we >also need overall windows instructions for our CBS. Arjen, could you supply >those please? > > > Alan, yes, I will look into this. I may need a couple of days, though. My plan is to stick closely to what CMake expects vis-a-vis these extra libraries (at least freetype, as there is a module for detecting that one). Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-30 06:52:02
|
Hi, >> Here are the cookbooks [for dealing with freetype2 on windows] > > Just now I have committed a change to the INSTALL file to put in a whole new > section concerned with our CBS. I have put in Unix instructions there and > also Werner's cookbooks for accessing freetype2 on windows. However, we > also need overall windows instructions for our CBS. Arjen, could you supply > those please? Wouldn't it be helpful, if we would have a wiki for that? I actually use a local wiki (wikiPad) to put all the notes down for plplot. For Linux the CBS is not too complicated, since you normally just need to install a library or the devel package and you're done. On Windows much more work is needed. And the cookbooks change all the time, if the CBS is changed at least now at the beginning. A wiki would allow that people would collaboratively work on such cookbooks, with remarks and so on. We could than copy the "settled" parts into the INSTALL file. I could actually set up a wiki (mediawiki or plwiki) on my server space if this is thought to be a good idea. On the sourceforge space it's also possible I think. > > Thanks, Werner, for your work actuating plfreetype on windows. I assume > that makes the wingcc results look a lot better. That work should also make > the gd-related device results look a lot better once you or Arjen get those > devices working on windows. Yes, wingcc looks much better. I'll have a look into the gd library integration soon. Regards, Werner |
From: Arjen M. <arj...@wl...> - 2006-08-30 06:26:05
|
Werner Smekal wrote: > Hi, > > in order to make plplot run with the freetype library on win32, some > changes need to be done (patch attached): > Hi Werner, where do you recommend to install the freetype library? That has been one of my worries when I tried to enhance the win3 driver with GD and freetype. I think a clear recommendation for our users (which makes it easy for CMake to find the stuff) is needed. Similarly for the GD library of course. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-30 06:40:52
|
Hi Arjen, the problem is, that there is no standard folder for it in Windows, so - in my opinion - the only way is to tell cmake where to find the libraries and headers via environment variables. For example my folder structure looks like this c:\DevZone\plplot c:\DevZone\freetype-2.2.1 c:\DevZone\gd and in order to make the freetype library known to cmake: set FREETYPEDIR=C:\DevZone\freetype-2.2.1 set PATH=%FREETYPEDIR%\objs;%PATH% set CMAKE_INCLUDE_PATH=%FREETYPEDIR%\include But you could put the freetype folder wherever you want, as long as you set PATH and CMAKE_INCLUDE_PATH correctly. I use a batch file for every compiler I use, where everything is set up, also the env. variables above. This is necessary, since I have 5 different compilers on my computer, and making the variables global would mix everything. Another possibility would be to put freetype in a folder relative to the plplot folder, so the cmake can find it (by changing the *.cmake files), but this needs also to be explained to the programmer so there is no advantage for this. And I also think this is not the best solution. Another possibility would be, that we change the cmake files, that they also look in FREETYPEDIR and GDDIR for the necessary headers and libs. So than you would only need to set these two and cmake does the rest and no need to change the PATH and CMAKE_INCLUDE_PATH variables. So the programmer only sets these variables. This would be my prefered solution actually - but you need to change the corresponding cmake files - I don't know if Alan agrees here. Regards, Werner Arjen Markus wrote: > Werner Smekal wrote: > >> Hi, >> >> in order to make plplot run with the freetype library on win32, some >> changes need to be done (patch attached): >> > Hi Werner, > > where do you recommend to install the freetype library? That has been > one of > my worries when I tried to enhance the win3 driver with GD and freetype. > I think a clear recommendation for our users (which makes it easy for CMake > to find the stuff) is needed. Similarly for the GD library of course. > > Regards, > > Arjen -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <aro...@ya...> - 2006-08-30 07:24:09
|
At 08:40 AM 30/08/2006 +0200, you wrote: >the problem is, that there is no standard folder for it in Windows, so - >in my opinion - the only way is to tell cmake where to find the >libraries and headers via environment variables. For example my folder >structure looks like this > >c:\DevZone\plplot >c:\DevZone\freetype-2.2.1 >c:\DevZone\gd Agreed. Mine (for example) live in: C:\dev\MinGW\contrib How hard would it to be add the default compiler search path ? GCC uses LIBRARY_PATH, C_INCLUDE_PATH, COMPILER_PATH, and CPLUS_INCLUDE_PATH for example. I have my "C:\dev\MinGW\contrib" embedded within those paths somewhere, and autotools was always able to find my libraries by searching those variables. >Another possibility would be to put freetype in a folder relative to the >plplot folder, so the cmake can find it (by changing the *.cmake files), >but this needs also to be explained to the programmer so there is no >advantage for this. And I also think this is not the best solution. I agree. I think just about everyone will have it in different places. Just like how I dislike installers which don't ask me where I want to put their programs, even if I would have put them where the installer wanted to. -Andrew |
From: Werner S. <sm...@ia...> - 2006-08-30 08:09:08
|
Hi, Andrew Roach wrote: > At 08:40 AM 30/08/2006 +0200, you wrote: >> the problem is, that there is no standard folder for it in Windows, so - >> in my opinion - the only way is to tell cmake where to find the >> libraries and headers via environment variables. For example my folder >> structure looks like this >> >> c:\DevZone\plplot >> c:\DevZone\freetype-2.2.1 >> c:\DevZone\gd > > Agreed. Mine (for example) live in: C:\dev\MinGW\contrib > > How hard would it to be add the default compiler search path ? GCC uses > LIBRARY_PATH, C_INCLUDE_PATH, COMPILER_PATH, and CPLUS_INCLUDE_PATH for > example. I have my "C:\dev\MinGW\contrib" embedded within those paths > somewhere, and autotools was always able to find my libraries by searching > those variables. This would also be an option, but I have to admit, that I don't know to change the search path for any compiler I work with (except gcc now :). So we would need to provide this information for all compilers we support. Here it would be better, to just say "set FREETYPELIBDIR..." and the rest is done by cmake. I also just read in the INSTALL file, that something similar is done on Linux for the ABS. Regards, Werner |
From: Alan W. I. <ir...@be...> - 2006-08-30 17:32:34
|
On 2006-08-30 08:40+0200 Werner Smekal wrote: > Hi Arjen, > > the problem is, that there is no standard folder for it in Windows, so - > in my opinion - the only way is to tell cmake where to find the > libraries and headers via environment variables. For example my folder > structure looks like this > > c:\DevZone\plplot > c:\DevZone\freetype-2.2.1 > c:\DevZone\gd > > and in order to make the freetype library known to cmake: > > set FREETYPEDIR=C:\DevZone\freetype-2.2.1 > set PATH=%FREETYPEDIR%\objs;%PATH% > set CMAKE_INCLUDE_PATH=%FREETYPEDIR%\include > > But you could put the freetype folder wherever you want, as long as you > set PATH and CMAKE_INCLUDE_PATH correctly. > > I use a batch file for every compiler I use, where everything is set up, > also the env. variables above. This is necessary, since I have 5 > different compilers on my computer, and making the variables global > would mix everything. Here is my response to this entire thread so far including Andrew Roach's post. I think the above approach is the correct one. In the CMake world it is the user's responsibility to help CMake find those system components _that have been installed in non-standard locations_ by setting environment variables. That philosophy runs throughout the project, and I just think it would consume too much of our energy to try and change where CMake has drawn the line between what is considered standard and what is considered non-standard by adding (and maintaining) extra search locations in our modules as well as all the standard CMake modules that we use. That introduces the question of what CMake considers to be the standard install locations on Windows systems. Andrew, have you tried CMake yet to see whether it has a problem finding the system components you feel are installed in a standard location? Cmake may agree with you that is a standard install location for windows so you may be anticipating a problem that does not exist. Also, if there is some obvious standard install location that CMake has missed on a given platform, I suggest you submit a CMake wishlist bug report. I find their developers are quite amenable to acting on such bug reports to improve CMake. Werner, I think your idea of a wiki to help user's out with the PLplot CBS on various platforms is an excellent one. There is a lot of lore we are rapidly accumulating as a group for the best way to interact with the PLplot CBS on various platforms, and I think a wiki would be ideal for organizing all that information (including the current issue of what environment variables to set so that CMake will find a freetype library that has been installed in a non-standard location). I just did a quick search through the SF documentation and could not find out anything relevant to setting up wikis as part of a SF project web site. So you may have to set up and host that wiki yourself. If you do that, we should be sure and advertise it prominently on our SF web site. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2006-08-31 02:39:02
|
At 10:32 AM 30/08/2006 -0700, Alan wrote: >That introduces the question of what CMake considers to be the standard >install locations on Windows systems. Andrew, have you tried CMake yet to >see whether it has a problem finding the system components you feel are >installed in a standard location? I have tried CMake, but really I am not sure what constitutes a "standard=20 location". For MingW, the only real standard is the =85\mingw\lib directory= =20 which comes with all of the stock libraries distributed with package.=20 Personally, I prefer to keep an additional "lib" and "include" directory in= =20 =85\mingw\contrib, with any additional libraries that aren't in MingW's=20 standard pack. Autotools always finds them because they are set in=20 COMPILER_PATH and INCLUDE_PATH. CMake doesn't, so I have to do it manually. >Cmake may agree with you that is a >standard install location for windows so you may be anticipating a problem >that does not exist. My "contrib" sub-directory isn't "standard", but at the same time, it's=20 also not uncommon - some other libs choose to embed themselves there by=20 default, which is why I have continued the practice. So it isn't surprising= =20 that Cmake doesn't look there. >Also, if there is some obvious standard install >location that CMake has missed on a given platform, I suggest you submit a >CMake wishlist bug report. I still think that it should search the default include and library search= =20 paths used by GCC - I think that would save big headaches all round.=20 Probably a CMake issue rather than our scripts. One curious thing that I have noticed is that for the libraries, CMake more= =20 often than not picks up the DLLs in windows/system, which is unfortunate=20 because while the *are* libraries, they aren't "stubs" (which end in=20 ".dll.a" not ".dll"), and MingW can't link to them directly. So I have to=20 go back and point it to where the stubs are. I am guessing that is CMake's= =20 doing and not the scripts ? >I find their developers are quite amenable to >acting on such bug reports to improve CMake. I'll pop over and report a rather annoying bug with the GUI version of=20 CMake which wont let you change a font name, even if a selector comes up=20 (when you try to choose another font, it just previews it). -Andrew |
From: Alan W. I. <ir...@be...> - 2006-08-31 05:13:31
|
On 2006-08-31 12:39+1000 Andrew Roach wrote: > At 10:32 AM 30/08/2006 -0700, Alan wrote: >> That introduces the question of what CMake considers to be the standard >> install locations on Windows systems. Andrew, have you tried CMake yet t= o >> see whether it has a problem finding the system components you feel are >> installed in a standard location? > > I have tried CMake, but really I am not sure what constitutes a "standard > location". For MingW, the only real standard is the =85\mingw\lib directo= ry > which comes with all of the stock libraries distributed with package. > Personally, I prefer to keep an additional "lib" and "include" directory = in > =85\mingw\contrib, with any additional libraries that aren't in MingW's > standard pack. Autotools always finds them because they are set in > COMPILER_PATH and INCLUDE_PATH. CMake doesn't, so I have to do it manuall= y. When you say "manually" do you mean setting CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH appropriately? I have headers and libraries installed i= n non-standard locations on my Debian stable and Ubuntu Dapper boxes so I always must use those environment variables. However, I set those environment variables with a script. Once that script is set up it is alway= s easy to prepare for CMake use. > One curious thing that I have noticed is that for the libraries, CMake mo= re > often than not picks up the DLLs in windows/system, which is unfortunate > because while the *are* libraries, they aren't "stubs" (which end in > ".dll.a" not ".dll"), and MingW can't link to them directly. So I have to > go back and point it to where the stubs are. I am guessing that is CMake'= s > doing and not the scripts ? I want to emphasize that all the many different find modules usually boil down to calls to the CMake FIND_FILE, FIND_PATH, FIND_LIBRARY, and FIND_PROGRAM commands. Those commands and the search strategies for them (including what environment variables are used to guide the search) are documented at http://www.cmake.org/HTML/Documentation.html. Let's take FindFreetype.cmake as a concrete example that we can look at in a bit of detail to clear up what is bothering you. (1) There is a search for freetype/config/ftheader.h using FIND_PATH. That search is guided by the CMAKE_INCLUDE_PATH environment variable. (2) There is a search for the "freetype" library using FIND_LIBRARY. That search is guided by CMAKE_LIBRARY_PATH. If I recall correctly, on Linux wha= t is returned in FREETYPE_LIBRARY is the absolute path+name of the .so form o= f the library, that is /usr/lib/libfreetype.so. CMake is smart enough to tur= n that absolute path+name into the -lfreetype link option. Normally, it also supplies the appropriate -L option as well, but not in this case because it knows /usr/lib is a standard library location on Linux and therefore not needed as a -L option. Could you post exactly what happens in the windows case for the freetype library search? I assume if the *.dll and *.dll.a forms of that library were in the same directory, then you point CMAKE_LIBRARY_PATH to that directory and CMake does the right think and returns the absolute path+name of the *.dll.a form in the FREETYPE_LIBRARY variable, and CMake does the right thing with that when linking. (Please confirm that if you have a case of *.dll and *.dll.a in the same directory.) If the *.dll and *.dll.a forms of the library are i= n different directories, then I assume you just point CMAKE_LIBRARY_PATH to the *.dll.a directory rather than the *.dll directory, and everything proceeds without problems. Thus, I don't understand why you seem to have some reservations about using CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to guide searches on windows, but that may just be due to my inexperience with windows. Don't those environment variables work the way I have inferred fo= r that platform from my Linux experience? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2006-08-31 11:13:05
|
At 10:12 PM 30/08/2006 -0700, you wrote: >When you say "manually" do you mean setting CMAKE_INCLUDE_PATH and >CMAKE_LIBRARY_PATH appropriately? No, I didn't have them set up properly before. >I have headers and libraries installed in >non-standard locations on my Debian stable and Ubuntu Dapper boxes so I >always must use those environment variables. However, I set those >environment variables with a script. Once that script is set up it is always >easy to prepare for CMake use. I actually meant setting the absolute library locations from within the CMake GUI for each of the libraries to point right to the directories they were in, not setting CMAKE_INCLUDE_PATH or CMAKE_LIBRARY_PATH to find them. After setting them correctly it is working now. >Let's take FindFreetype.cmake as a concrete example that we can look at in >a bit of detail to clear up what is bothering you. > >(1) There is a search for freetype/config/ftheader.h using FIND_PATH. That >search is guided by the CMAKE_INCLUDE_PATH environment variable. > >(2) There is a search for the "freetype" library using FIND_LIBRARY. That >search is guided by CMAKE_LIBRARY_PATH. If I recall correctly, on Linux what >is returned in FREETYPE_LIBRARY is the absolute path+name of the .so form of >the library, that is /usr/lib/libfreetype.so. CMake is smart enough to turn >that absolute path+name into the -lfreetype link option. Normally, it also >supplies the appropriate -L option as well, but not in this case because it >knows /usr/lib is a standard library location on Linux and therefore not >needed as a -L option. > >Could you post exactly what happens in the windows case for the freetype >library search? None of the logs showed what happened in the search - it all happened in the status bar of the Gui, but it works now I have set it up properly. >I assume if the *.dll and *.dll.a forms of that library were in the same >directory, then you point CMAKE_LIBRARY_PATH to that directory and CMake >does the right think and returns the absolute path+name of the *.dll.a form >in the FREETYPE_LIBRARY variable, and CMake does the right thing with that >when linking. (Please confirm that if you have a case of *.dll and *.dll.a >in the same directory.) Generally speaking, the .dll and the .dll.a's wont be in the same directory. Where Cmake was falling over before was, for example, in picking up different versions of libz, of which I have about six different versions all over my computer (almost every package that uses it, uses it's own version which isn't interchangeable). Some were in the default search path Cmake was using (in the absence of CMAKE_LIBRARY_PATH), and once Cmake found a matching .dll file it stopped looking for any stubs or anything else. >If the *.dll and *.dll.a forms of the library are in >different directories, then I assume you just point CMAKE_LIBRARY_PATH to >the *.dll.a directory rather than the *.dll directory, and everything >proceeds without problems. Yes, that is how I solved it. >Thus, I don't understand why you seem to have >some reservations about using CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to >guide searches on windows, but that may just be due to my inexperience with >windows. Don't those environment variables work the way I have inferred for >that platform from my Linux experience? They do, I had not set it up correctly, and assumed CMake would have automatically searched the default library paths of GCC if it could not find what it was looking for (as autotools did). -Andrew |
From: Werner S. <sm...@ia...> - 2006-08-31 13:38:59
|
Hi, I set up a wiki for Plplot here: http://www.miscdebris.net/plplot_wiki I chose mediawiki, since it should allow to include pictures/plots and so on easily (and my host provided an one-click install :) ). Anyway, there is not much information to be found - first it would make sense to build up a structure of all the information (sections, subsections and so on) we want to provide - I'm not too good in this, so if someone would start that (Alan?), I would happily fill in the information than :) So, everybody is welcome to add information to the wiki. Regards, Werner |
From: Werner S. <sm...@ia...> - 2006-08-31 14:53:59
Attachments:
plplot_bcc.patch
|
Hi Alan, attached is the patch for support of Borland C++ 5.5 free command line tool (bcc). Andrew also helped me to make the wingcc driver work with bcc (not included in this patch, Andrew committed it already). The library compiles without problem and also the c examples - the c++ examples have still the problem, that the compiler tries to link to a c.lib which doesn't exist. The Makefile doesn't has this library in the command call, but the compiler first complains if I add the plplotcxx.lib (if I do the compilation by hand). So there is maybe the problem. Google also didn't help much, since c.lib should actually not be needed. Arjen, could you try the newest wingcc driver by the way? Andrew has found the bug which lead to the complaint of the Visual C++ compiler, at least for Visual C++ 2005 there are is no complain about heap corruption any more. Please apply the patch if looks ok for you. Thanks, Werner |
From: Arjen M. <arj...@wl...> - 2006-08-31 14:57:15
|
> > Arjen, could you try the newest wingcc driver by the way? Andrew has > found the bug which lead to the complaint of the Visual C++ compiler, > at least for Visual C++ 2005 there are is no complain about heap > corruption any more. > > Please apply the patch if looks ok for you. > I already did that and I was happily surprised to find that the bug was gone. This is for MSVC/C++ - both C and C++ examples work fine now with wingcc. I added some information on how to use CMake on Windows in the INSTALL file. Could you check this? Any comments and additions welcome Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-08-31 17:18:04
|
On 2006-08-31 15:39+0200 Werner Smekal wrote: > Hi, > > I set up a wiki for Plplot here: > > http://www.miscdebris.net/plplot_wiki > > I chose mediawiki, since it should allow to include pictures/plots and so on > easily (and my host provided an one-click install :) ). > > Anyway, there is not much information to be found - first it would make sense > to build up a structure of all the information (sections, subsections and so > on) we want to provide - I'm not too good in this, so if someone would start > that (Alan?), I would happily fill in the information than :) > > So, everybody is welcome to add information to the wiki. I just proved I can modify something there without having an account. See http://www.miscdebris.net/plplot_wiki/index.php?title=Configure_PLplot_for_gcc_compiler_%28Linux%29 I think you need to configure your wiki to only accept changes from those who have logged in. That requirement forces all contributors to establish a valid account, and that seems quite an effective tool in discouraging spammers and defacers (who normally just want to randomly attack wikis where they don't have to do anything special such as establishing an account.) Note, I am not familiar with mediawiki configuration, but I assume there is a configuration option to only accept changes from logged in users because at least one other mediawiki site I have contributed to had that requirement. Once this issue is sorted out, I will be happy to contribute to this wiki. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2006-08-31 18:16:00
|
Hi Alan, you need now to be logged in to edit pages. We'll see in the future if further measurements against spammers are needed. Regards, Werner > Note, I am not familiar with mediawiki configuration, but I assume there is > a configuration option to only accept changes from logged in users because > at least one other mediawiki site I have contributed to had that > requirement. > > Once this issue is sorted out, I will be happy to contribute to this wiki. > > Alan -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2006-08-31 17:57:15
|
On 2006-08-31 16:53+0200 Werner Smekal wrote: > Hi Alan, > > attached is the patch for support of Borland C++ 5.5 free command line tool > (bcc). [...] > Please apply the patch if looks ok for you. I am Ccing this to Andy, one of our windows users, because he has already expressed interest in Borland and our new CMake build system. Werner, your patch looked okay, applied cleanly, and on Linux the resulting source tree built fine and ctest passed all tests. So I have just now committed your changes to CVS. Thus, bcc should now work fine for you from our CVS version except for the on-going problem with the C++ examples that you mentioned. Presumably somebody will be able to figure that issue out eventually. Thanks for your on-going efforts to polish and extend our CBS on windows. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-09-01 00:00:10
|
On 2006-08-31 20:15+0200 Werner Smekal wrote: > Hi Alan, > > you need now to be logged in to edit pages. OK. Thanks for that change which I think should be adequate for restraining most spammers and defacers. I have now established an account and have done a lot of editing there for the Unix CBS case following what was in the INSTALL file. I have also considerably reorganized the Wiki. Let me know what you think of the overall organization and the Unix CBS content I entered. mediawiki seems really easy to use so I encourage others here to establish accounts and edit http://www.miscdebris.net/plplot_wiki/ in their areas of PLplot expertise. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |