Re: [Plplot-general] wingcc drivers fails to build onWindows 7 64bit/VC

[Arjen M. <arj...@de...>]

Hi Rob,

as you do not care for C++, you can always switch it off using the
option -DENABLE_cxx:BOOL=OFF.

To solve the problem with the +'s in "g++", you might try to create a
link to that executable with an inconspicuous name. I am not sure if
that works under CMake (not sure these Windows links are transparant
enough), but it might be worth a try. Or use a batchfile instead.

Regards,

Arjen

On 2010-06-22 05:30, Sisyphus wrote:
> ----- Original Message ----- 
> From: "Alan W. Irwin" <ir...@be...>
> 
>>> -- The CXX compiler identification is unknown
>>> -- Check for working CXX compiler: g++.exe
> 
>> Assuming x86_64-w64-mingw32-g++.exe is on your PATH, my guess is the "++" 
>> is
>> causing problems in the name of the executable.  You may need to quote it
>> ('++') or even escape it inside quotes ('\+\+') before cmake can find that
>> executable for itself.  There is probably special code within CMake to
>> find g++.exe (with no prefix) without further help, but that is probably
>> not true of x86_64-w64-mingw32-g++.exe.
> 
> Haven't yet found a rendition that works. I've even created a copy of the 
> g++ executable called 'cpp.exe' and tried to use it. I've tried altering 
> CMAKE_CXX_COMPILER and CMAKE_CXX_COMPILER:FILEPATH, but it's always the same 
> error (as above). I think the failure to access cpp.exe indicates that 
> there's more to the problem than just the '+' symbols.
> It's as though there's a decision made somewhere in the sources that the g++ 
> executable has to be named 'g++.exe' and nothing else is acceptable.
> 
>>> Haven't yet worked out how I'm supposed to tell the process that 'ar.exe' 
>>> is
>>> really named 'x86_64-w64-mingw32-ar.exe' . Anyone know ?
>> What do you get for CMAKE_AR:FILEPATH in your CMakeCache.txt file?  If 
>> that
>> is not the correct value, I think you should be able to override it with
>> -DCMAKE_AR:FILEPATH=\whatever\path\to\ar\x86_64-w64-mingw32-ar.exe
>>
> 
> Yes, that works nicely. Thanks.
> 
>> Of course, the proper way to set platform-dependent constants is with a 
>> new
>> or modified file in (e.g., $prefix/share/cmake-2.8/Modules/Platform/.
>> However, platform files are sometimes a difficult topic, so I would report
>> what constants you need to set with -D to the CMake developers at the
>> cm...@cm... mailing list with an exact description of your platform so
>> they can figure out what platform file changes need to be done to
>> make the experience for the next user of your platform much smoother.
> 
> Most people who build with MinGW64 use the "sezero" version of the compiler 
> where the various executables (gcc, g++, ar, etc.) are given their usual 
> names. The only problems they will come up against are the wingcc.c code 
> (already fixed in svn) and the absence of a correct library path in the 
> MINGWLIBPATH list in CMakeLists.txt. Once that has been taken care of, 
> they're right to go without any need for changes to platform files.
> 
> As regards the extra requirements that need to be met when the 
> cross-compiler is being used, I'll consider raising it with the developers 
> as you suggest - though I'm not sure that setting up new platform files just 
> to accommodate the mingw64 cross-compiler is really worth the effort (given 
> that very few seem to use that particular compiler, and those that do 
> probably accept that they need to take some extra steps themselves). A 
> ,mention on how to build with the cross-compiler on the wiki might be handy, 
> however.
> 
> Anyway, I'd like to first work out why I can't get the build process to use 
> x86_64-w64-mingw32-g++.exe.
> 
> Thanks muchly for the pointers.
> 
> Cheers,
> Rob 
> 
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>