Compiling MPIR with Visual Studio 11 Developer Preview...

[Steve]

In an attempt to verify some code I've written using MPIR and Visual C++
2010 Express (which only supports generating 32-bit executables) I
downloaded Visual Studio 11 Developer Preview - which gives me access to
an effective beta of the next version of Visual Studio Ultimate
Edition. My motivation has been to verify that my code is efficient in
both 32 and 64-bit windows environments - and to detect any potential
errors with respect to presumed register sizes. I also hoped to
benchmark the 64-bit build against the 32-bit build to establish if
there is a strong motivation for investing in a 64-bit Windows C++ compiler.

I've attempted to build the MPIR project by importing the Visual Studio
10 solution as provided in 2.4.0, but have run into difficulties that
didn't present themselves with Express Edition. Building with the IDE
caused the IDE to hang at link time. I also tried building
VS11-Developer-Preview using the batch files - which appears to generate
lib files - but they don't appear to contain the necessary symbols - I
can't link successfully against them.

I'm not surprised to find that there are glitches building MPIR using
the preview release of Visual Studio - but I'd like to know if others
have run into similar difficulties - and, if so, how they've resolved
them. I'd like to avoid duplicating effort unnecessarily...

[Case Van Horsen]

On Sun, Nov 6, 2011 at 8:02 AM, Steve <sjh_g...@shic.co.uk> wrote:
> In an attempt to verify some code I've written using MPIR and Visual C++
> 2010 Express (which only supports generating 32-bit executables) I
> downloaded Visual Studio 11 Developer Preview - which gives me access to
> an effective beta of the next version of Visual Studio Ultimate
> Edition.  My motivation has been to verify that my code is efficient in
> both 32 and 64-bit windows environments - and to detect any potential
> errors with respect to presumed register sizes.  I also hoped to
> benchmark the 64-bit build against the 32-bit build to establish if
> there is a strong motivation for investing in a 64-bit Windows C++ compiler.
>

I've used the Windows 7 SDK to compile MPIR in both 32- and 64-bit
mode. I just used the batch file approach but I believe the SDK will
add a 64-bit compiler to Visual Studio Express. IIRC, the 7.0 SDK
corresponds to VS 2008 and the 7.1 SDK corresponds to VS 2010.

casevh

> I've attempted to build the MPIR project by importing the Visual Studio
> 10 solution as provided in 2.4.0, but have run into difficulties that
> didn't present themselves with Express Edition.   Building with the IDE
> caused the IDE to hang at link time.   I also tried building
> VS11-Developer-Preview using the batch files - which appears to generate
> lib files - but they don't appear to contain the necessary symbols - I
> can't link successfully against them.
>
> I'm not surprised to find that there are glitches building MPIR using
> the preview release of Visual Studio - but I'd like to know if others
> have run into similar difficulties - and, if so, how they've resolved
> them.  I'd like to avoid duplicating effort unnecessarily...
>
>

> --
> You received this message because you are subscribed to the Google Groups "mpir-devel" group.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
>
>

[Steve]

On 06/11/2011 16:10, Case Van Horsen wrote:
> I've used the Windows 7 SDK to compile MPIR in both 32- and 64-bit
> mode. I just used the batch file approach but I believe the SDK will
> add a 64-bit compiler to Visual Studio Express. IIRC, the 7.0 SDK
> corresponds to VS 2008 and the 7.1 SDK corresponds to VS 2010.

Thanks, I hadn't realised that I could use the freely available SDK to
build 64-bit C++ applications. That's good to know for its own sake.

I've run into yet more glitches - I've installed the 7.1 SDK and run the
"Windows SDK 7.1 Command Prompt"... no matter what configuration I
choose using setenv, MPIR refuses to build... this time it appears to be
some sort of problem with pre-processor definitions... or,
alternatively, I'm making some kind of error with configuration...

> C:\usr\CPPLibs\MPIR-2.4.0\win> setenv /debug /x64
> Setting SDK environment relative to C:\Program Files\Microsoft
> SDKs\Windows\v7.1
> \.
> Targeting Windows 7 x64 Debug
>
> C:\usr\CPPLibs\MPIR-2.4.0\win> configure.bat
> setting params to
> (set LIBTYPE=lib)
> (set FLAGS=/Ox /Ot /D "NDEBUG" /D "HAVE_CONFIG_H" /nologo /D "_MBCS" /GS-)
> (set FLAGS1=/Oi /D "_LIB" /D "PIC" /MT)
> (set MPNPATH=x86_64w x86_64w\nehalem x86_64w\nehalem\westmere)
> (set ABI=64)
>
> C:\usr\CPPLibs\MPIR-2.4.0\win> make.bat
> 1 file(s) copied.
> 1 file(s) copied.
> 1 file(s) copied.
> 1 file(s) copied.
> creating mpir.h for x64
> overwriting ..\\mpir.h with tmp.h
> add.c
> ..\..\mpir.h(1404) : error C2143: syntax error : missing ')' before
> 'constant'
> ..\..\mpir.h(1404) : error C2059: syntax error : ')'
> ..\..\mpir.h(1721) : error C2065: 'GMP_NAIL_BITS' : undeclared identifier
> ..\..\mpir.h(1721) : warning C4090: '=' : different 'const' qualifiers
> ..\..\mpir.h(1757) : error C2065: 'GMP_NAIL_BITS' : undeclared identifier
> ..\..\mpir.h(1757) : warning C4090: '=' : different 'const' qualifiers
> ..\..\gmp-impl.h(244) : fatal error C1189: #error : no data available
> for this limb size in perfsqr.h
> ERROR

Lines 1402 to 1405 of ..\..\mpir.h read:

> #if GMP_NAIL_BITS == 0 || defined (_LONG_LONG_LIMB)
> /* limb==long and no nails, or limb==longlong, one limb is enough */
> return (unsigned long)(__gmp_n 0);
> #else

[Cactus]

It looks like the script that creates mpir.h is not working properly.   

Do you have something like the following early in mpir.h?

#if ! defined (__GMP_WITHIN_CONFIGURE)

#define __GMP_BITS_PER_MP_LIMB              64

#define GMP_LIMB_BITS                       64

#define GMP_NAIL_BITS                       0 

#define SIZEOF_MP_LIMB_T (GMP_LIMB_BITS >> 3) 

#if !defined _LONG_LONG_LIMB

#  define _LONG_LONG_LIMB 1 

#endif

#if !defined _WIN64

#define _WIN64 

#endif

#endif

Have you tried the IDE based build?

     Brian

[Steve]

I have something very line that - except that the "!" characters are
missing in my version... I have:

> #if defined (__GMP_WITHIN_CONFIGURE)
> ...
> #if defined _WIN64

Is this a general problem with the 2.4.0 release, or is it something
specific to my environment?

> Have you tried the IDE based build?

That's how I built the 32-bit libraries using the Express edition - and
it worked well enough. I also tried the IDE-based build with
VS11-developer-preview, and that had lots of problems.

[Cactus]

I think it would be useful to find out why GMP_NAIL_BITS is not being defined.  It appears to be because the section I referenced is not being included when I think it should be.

It would be useful to put the ! marks back in but this won't work because the file is being generated from gmp-h.in so it will simply get overridden. 

Can you look at gmp-h.in to see if it has the exclamation marks?

[Steve]

The gmp-h.in file has the exclamation marks. I've tracked down the
problem to gen_mpir_h.bat. It seems, when the batch file is evaluated
in my environment, the ! character is shell-expanded to nothing.

I'm not clear why this is a problem for me, but -presumably- not for
others. I'm using a vanilla "Microsoft Windows SDK v7.1" on Windows 7
'Home Premium' Build 7601, Service Pack 1.

[Cactus]

Hi Steve,

I have just installed the Visual Studio Developer Preview 11.

Note that, in addition to installing Visual Studio 11, the YASM assembler -- vsyasm.exe -- has to be copied into the directory holding the VC++ version 11 binaries.

After the automatic upgrade of the version 10 build files to the version 11 format, VC++ v11 built both MPIR and the tests perfectly with the IDE based build files.  And all tests passed.

I have had a look at the command line build (which I don't use or maintain - this is Jason's baby).

I would not expect these to work unless you extensively edit them since a lot of the paths are hardcoded to pick up the Visual Studio 10 tools.

 

I am happy to help in getting the IDE builds to work for you with VC++ 11 but you will need to work with Jason if you want to use the command line builds.  

Another alternative if you have a modern Python installed (2.7, 3.x) is to use my experimental mpir_config.py to generate a VC++ 10 IDE build and then use VC++ 11 to automatically convert it to the version 11 format. But this should not be different to using an existing upgraded build so its a bit of a 'last straw'   

[Steve]

On 07/11/2011 11:21, Cactus wrote:
> I have just installed the Visual Studio Developer Preview 11.
>
> Note that, in addition to installing Visual Studio 11, the YASM
> assembler -- vsyasm.exe -- has to be copied into the directory holding
> the VC++ version 11 binaries.

I've got a copy of vsyasm.exe in both:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\vsyasm.exe

and

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\vsyasm.exe

As far as I can tell, that bit works.

> After the automatic upgrade of the version 10 build files to the
> version 11 format, VC++ v11 built both MPIR and the tests perfectly
> with the IDE based build files. And all tests passed.

I've tried again... a freshly extracted mpir_2.4.0, and a fresh instance
of visual studio 2011. I get different behaviour today (though I'm not
aware of anything substantially different, from an end-user perspective,
between this and my previous attempts... same software; same source
code; same general approach... though, of course, I can't be sure that I
took exactly the same steps in exactly the same order.

On my most recent build attempt to build using the VS11 ide, 2 projects
succeeded - and 7 failed, generating 18865 lines of warnings/errors,
some of which look very suspicious. A common message is:

"The process cannot access the file because it is being used by another
process."

I've bzipped all the errors that arose when I did 'Build solution"
immediately after a successful upgrade of the build files - attached, FYI.

There's definitely something awry - perhaps it's a concurrency issue
with the build environment/solution?

> I have had a look at the command line build (which I don't use or
> maintain - this is Jason's baby).
>
> I would not expect these to work unless you extensively edit them
> since a lot of the paths are hardcoded to pick up the Visual Studio 10
> tools.

I've started delving through these - and have to admit - it would
probably take quite a while to establish why gen_mpir_h.bat is eating
"!" characters (just for me?) ... and that's before I wonder about
hard-coded paths. I'd assumed that these paths would all come from the
environment - as each different install of compiler tools comes with a
'configured command prompt' that ensures consistency... and makes it
easy to build from a command line in a variety of environments without
altering build scripts for each.

> I am happy to help in getting the IDE builds to work for you with VC++
> 11 but you will need to work with Jason if you want to use the command
> line builds.

With a 'selfish' hat on, I don't much care which approach I use...
though I'm happy to help where I can, and suspect others, in future,
would appreciate both approaches. The VS builds pave the way for
developers to delve into the source - while the command line builds make
it easier to just 'use' the library when building projects that just
depend upon it.

> Another alternative if you have a modern Python installed (2.7, 3.x)
> is to use my experimental mpir_config.py to generate a VC++ 10 IDE
> build and then use VC++ 11 to automatically convert it to the version
> 11 format. But this should not be different to using an existing
> upgraded build so its a bit of a 'last straw'

I do have Python - though I've not tried mpir_config.py... I suspect it
would just show similar problems to those with the supplied solution
files... I don't think anything went wrong with the upgrade of the
solution/project files... Perhaps the glitches appear for me on account
of my OS and hardware? I'm building on a laptop with an i5 processor,
6Gb RAM and Windows-7 "home".

[Cactus]

The "file is being used by another process" message is because several builds are running at the same time.  

If you want to build all the projects, it is safer to configure the IDE not to use parallel builds.  

This should avoid the problem you are seeing.

[Steve]

On 07/11/2011 13:01, Cactus wrote:
> The "file is being used by another process" message is because several
> builds are running at the same time.

I'd guessed that there was a link... though, ideally, the solution files
would be written in such a way as to allow non-dependent projects to be
built simultaneously.

Today, I've tried building each individual project separately - and this
has worked. I tried the same thing yesterday - and it didn't... I'm
assuming that this was because some intermediate files had been
corrupted in a previous build attempt.

> If you want to build all the projects, it is safer to configure the
> IDE not to use parallel builds.

Ah-ha... that avoids the issue, too. The (different) error messages
yesterday were less obvious... well - that's my story and I'm sticking
to it. :)

> This should avoid the problem you are seeing.

It does... Of course, it would be desirable if the solution files worked
irrespective of this build environment configuration... particularly if
MPIR were to be built by continuous integration systems as well as
interactively by the end user... Perhaps in the next release?

The bath-build issues remain a mystery... but nothing now stands in the
way of my 64-bit experiments...

Thanks for your assistance.

[Cactus]

I pleased it's now working for you. I'm happy to help further if necessary.

Its quite hard to make the whole build process completely automatic and fully parallel.  This would involve a lot of work, which means it probably won't happen unless someone volunteers to do it.

The IDE build as it is now is only designed to allow a user to select the version they want and then build and test it.  

Asking the whole solution to build rather than a single project is fraught with a whole host of difficulties and is not supported (some build requirements will fail if this is done).

    Brian