[mpir-devel] Ignore my message

[Brian Gladman]

Apologies for the previous message that was sent in error.

  Brian

--
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/8fd00cd1-6ad0-b190-a4dd-7b323a22b33d%40gladman.plus.com.

[mpir-devel] Re: [GURU Accounts #20220803-VC41] How to change login username

[Brian Gladman]

On 03/08/2022 19:39, GURU Accounts wrote:

Brian,

Apologies for the delay in this reply.

You can change the email address for your account via the option at the top 
right in the GURU portal.

Log in at https://my.guru.co.uk then click on the 'Hello, Brian!' top right and 
select Edit Account Details.

Please let me know if you have any issues changing your contact email address 
or there is anything else we can help with.


Hi Andrew

Thank you for your rapid response.  My problem is I when I log in it 
asks for an email address and this is set to b...@gladman.plus.com is not 
related to the email address I set on my account.


For example my email address on my account is reiman...@gmail.com but if 
I try to use this as my sign in email address it fails.


SO my question is, how do I change the email address that I have to use 
when I sign in on the GURU sign in page?


  regards,

 Brian

--
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/7550a487-7e67-33ee-e88f-eae0a6534f55%40gladman.plus.com.

Re: [mpir-devel] How to compile mpirxx.dll on windows with msvc

[Brian Gladman]

On 08/08/2020 06:59, wei zhao wrote:
> hi all,
> 
>  I downloaded mpir from github.com/BrianGladman.git. when I open
> msvc/vs10/mpir.sln I found three projects,  dll_mpir.gc, lib_mpir_cxx,
> lib_mpir_gc.
> 
>  lib_mpir_cxx generates a static lib, i need a dynamic one, I tried
> change it to dynamic libary but compile failed, showing a lot of
> unresolved external symbols.
> 
> anybody knows how to compile a dynamic mpirxx lib ? thanks in advance.

There is no dynamic mpirxx library

You should build the The DLL library, dll_mpir_gc, which provides both
the C and C++ MPIR functions.

The MPIR manual explains how to build assembler optimised versions if
you need them.

  Brian Gladman

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/a1c6007f-e2a2-8bdc-9b75-6ec09fbc1ddf%40gladman.plus.com.

Re: [mpir-devel] Re: Flint-2.6.0 alpha release (testing requested)

[Brian Gladman]

On 20/05/2020 17:40, 'Bill Hart' via mpir-devel wrote:
> Hi again,
> 
> Commit a960857c7d8e5ea7c4d4c2958e38ec52778d85d9  of the Flint
> repository [1] is now flint-2.6.0-alpha2
> 
> This is the last chance for developers working on related projects to
> see if Flint works as expected for them, before we start asking end
> users/distributions to start testing.

I tested the release (that you announced recently) on Windows (with my
Visual Studio build) and all tests passed.

I can't test the new release immediately but I will hopefully be able to
check it within the next few days.

> We have made many modifications since alpha1, including:
> 
> * removing all known memory leaks
> * fixing a bug in the integer gcd (leak, inefficiency, very slim
> chance of wrong answer)
> * properly supporting GMP-6.2
> * making matrices with zero rows/columns more robust
> * many other less important fixes (35 commits total)
> * fixing a bug/crash in the _f functions in the fmpz_mod_poly module
> 
> We don't foresee the need for any further alpha releases, (assuming no
> major issues are found). The next release will likely either be a beta
> or release candidate. Please note the only important things that
> remain to be done as far as we know are documentation/paperwork
> related [2].

The Visual Studio build documentation is out of date and we now have the
CMake build on Windows that needs documentation.

I am happy to provide an update of the Visual Studio build documentation
but I can't help with CMake.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/7d35b4ed-2382-54c6-f92f-f5e97af1e5c0%40gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

[Brian Gladman]

On 28/04/2020 23:28, 'Bill Hart' via mpir-devel wrote:
> You may be right, but I don't see where your files are in our repo:
> 
> https://github.com/wbhart/flint2 
> 
> This would be better discussed on the flint list as Isuru Fernando could
> chime in. He understands CMake much better than I do. I don't want to
> make assertions about it, as they often prove to be wrong.
> 
> Perhaps you could open a ticket with your observations on my Flint repo?

I don't know a lot about CMake but I haave taken a look and, as far as I
can see, it is no longer dependent on my build files.

But the Appveyor script in the Flint root directory DOES run my build
system and is not hence testing the output of the CMake build.

So if you are relying on Appveyor you will be running my out of date
build and judging its output rather than the CMake build output.

I'll ask about this on your repo.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/27a524b4-e9ee-43ac-234f-1d511cdbb383%40gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

[Brian Gladman]

On 28/04/2020 22:48, 'Bill Hart' via mpir-devel wrote:
> They both take about 0.6s with our continuous integration. I don't know
> if @tthsqe12 would expect them to randomly hit a really hard case?
> 
> https://ci.appveyor.com/project/wbhart/flint2/builds/32491737/job/1os2ex9o3pe53bhe
>  

I was under the impression that the Flint MSVC Windows build was no
longer dependent on my build system.  But I am now suspicious that you
might still be relying on my build as a basis for the CMake build.

If I am right, I am afraid that the build will be out of date and will
not be correct unless the test build generator has been run to keep it
aligned with the Flint source code.

Otherwise its hard to explain why my results are different.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/2355978b-67fc-1200-0d63-b4bc6f3765c4%40gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

[Brian Gladman]

On 28/04/2020 15:44, 'Bill Hart' via mpir-devel wrote:

> That's great news, thanks Brian.

I fear that I have reported a complete pass too early as I missed the
fact that my test code had to abort two tests after running for too long
(over 120 seconds).  These are:

  fmpq_mpoly/t-gcd.exe
  fmpq_mpoly/t-gcd_cofactors.exe

I have just run them both manually and neither finsihed within the five
minutes I gave them.  Should I expect to take longer then this?

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/4c21c68f-510f-dc35-5723-e0480c10f038%40gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

[Brian Gladman]

On 28/04/2020 00:06, Bill Hart wrote:
> Dear Brian,
> 
> MSVC 32 and 64 bit are now completely passing in out continuous
> integration with our trunk branch.
> 
> Could you possibly test this and see if it works for you. We are of
> course using CMake to generate the build files and I know you have your
> own solution files.
> 
> I'd be interesting to hear whether you still have the t-minpoly failure.
> Can you tell me what ERROR 3 is? That is not printed by our test code
> and it should in fact print a failure message with some diagnostic
> information if the test fails.
> 
> I've opened a ticket for this issue until it is resolved, but there's
> nothing more I can do for now without further information as we are
> unable to reproduce it.

THe name change of  config.h to flint-config.h was an initial issue for
me but this is fortunately easy to fix.  I have built and tested the
trunk branch of FLINT on Windows x64 and all tests pass.

I am not running win32 builds these days as I consider them obsolescent
but there is no reason to believe that they wont build if anyone wants
to run them.

The fmpq_mat/t-minpoly test passes and is not a FLINT code issue. I have
tracked this down to a failure somewhere in my automted code to build
and run the tests (why it fails one just one of well over 1000 tests is
a puzzle but I suspect a naming anomaly of some kind).  Anyway, I have
double checked by running this this test manually and it passes so the
ticcket can be closed.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/cc2bae2e-fa20-e5a0-c500-fe17fa2b09ed%40gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

[Brian Gladman]

On 21/04/2020 16:50, 'Bill Hart' via mpir-devel wrote:
> Isuru reinserted the necessary line FLINT_DLL const unsigned int
> partitions_lookup[128];
> 
> Perhaps you could check if this works for you now.

It builds fine. The tests give one error:


1523 tests:
1522 ran correctly
1 failed
fmpq_mat: t-minpoly ERROR 3 minpoly


I have not yet retested Arb integration though.  But it should be OK

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/aecec632-87af-95b8-efc4-231d6c669387%40gmail.com.

[mpir-devel] FLINT and ARB using Visual Studio

[Brian Gladman]

Hi Bill and Fredrik,

Being in CORVID lockdown, I decided to have a look at building Arb with
Visual Studio. This has gone pretty well but I have a few issues on
which I would appreciate your advice.

I can compile and build Arb as a static library without any issues but
building Arb as a DLL fails because it needs two flint export ssymbols
that are not present in the FLINT DLL.

The first of these is '__flint_clz_tab' which I find can be switched on
in FLINT by defining NEED_CLZ_TAB when building FLINT. This should not
be a problem since I can modify my FLINT build to do this.

The second missing symbol is 'partitions_lookup', which is defined in
the FLINT file 'number_of_partitions.c' where it does have an export
definition. But this is not visible to Arb because it this symbol is not
declared in flint.h or, as far as I can tell, in any other exported
FLINT header.

So is this a symbol that FLINT should export and, if so, where should
the export declaration be placed?

Another issue I am keen to tidy up is library location and naming.  I am
using simple names for the mpir dependent Windows builds: mpir, mpfr,
pthreads, ... and adding extensions 'lib and .dll accordingly.

For example, MPIR is in a root directory callled 'mpir' and within this
directory I have lib, dll, and exe sub-directories where I place the
mpir.lb, mpir.dll and mpir.exe build outputs. The same structure applies
to mpfr, pthreads but for FLINT I have been using the directory 'flint2'
rather than 'flint' and 'lib_flint.lib' and 'dll_flint.dll' for the
libraries (I am not sure why!)

In order to get a consistent approach now that I am adding Arb, I would
like to use the directory 'flint' rather than 'flint2' as the root
directory for FLINT and use the names 'flint.lib' and 'flint.dll' for
the libraries. But before I do this I would like to know if this change
is going to cause any issues for others (I am aware the the CMake FLINT
build depends on my FLINT build, which is why I am asking).

with my regards,

  Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/b0d4c8ab-8f2e-b1a3-0327-72f8d9e0557a%40gmail.com.

Re: [mpir-devel] Can autoconfigure be done without YASM

[Brian Gladman]

On 05/10/2019 16:11, David Lindauer wrote:
> Is it possible to configure the autoconfigure to use an assembler other
> than YASM on windows?   I'm asking because I have an assembler that
> should do gas-like constructs that I'd like to test with MPIR.

I don't know whether it will do what you want but YASM has a gas mode
and can assemble using AT&T syntax.   But I have never used it and don't
know how comprehensive it is.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/1928c541-ed85-87f8-add0-768da04c6ac8%40gladman.plus.com.

Re: [mpir-devel] MPIR.NET

[Brian Gladman]

On 06/06/2019 18:32, Dima Pasechnik wrote:

Hi Dima,

Good to hear from you!

[snip]
> 
> mpir.net  domain name is for sale, it appears.

I was referring the the MPIR.NET sub-project within MPIR - it providess
an API for access to MPIR from the Microsoft .NET framework.

> Did you try opening an issue on 
> https://github.com/adyache/mpir ?
> (I guess https://github.com/adyache is the github profile of the person
> in question)

Yes that's the right person but, unfortunately, he hasn't switched
'issues' on so its not available.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/c4fc5ae4-3174-ce7d-f774-bdeb80deee00%40gladman.plus.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: Fail on mpir-3.0 build

[Brian Gladman]

On 02/05/2019 10:44, degski wrote:
> On Thu, 2 May 2019 at 08:30, Cactus  > wrote:
> 
> Unfortunately I am away at the moment so I am a bit limited in what
> I can do to help until Tuesday next week.  I have tried the
> broadwell_avx build and it does produce errors for me as well, but
> oddly, not the error you are seeing.
> 
> 
> I was tracking my problem in/with the basic broadwell build, that one
> works. The broadwell_avx gives (a.o.):
> 
> 1>  Assembling and_n.asm ==> x64\Debug\and_n.obj
> 1>  ..\..\..\mpn\x86_64w\broadwell\avx\and_n.asm(117): error : undefined
> symbol `SizeB' (first use)
> 1>  ..\..\..\mpn\x86_64w\broadwell\avx\and_n.asm(117): error : (Each
> undefined symbol is reported only once.)
> 1>  ..\..\..\mpn\x86_64w\broadwell\avx\and_n.asm(152): error : undefined
> symbol `CountB' (first use)
> 1>  Y:\REPOS\mpir\msvc\vsyasm.targets(81,5): error MSB3721: The command
> ""C:\Program Files\yasm\"vsyasm.exe -Xvc -f x64 -g cv8 -i
> "..\..\..\mpn\x86_64w\\" -o "..\..\..\mpn\and_n.obj" -rnasm -pnasm  
> ..\..\..\mpn\x86_64w\broadwell\avx\and_n.asm" exited with code 1.
> 
> Which seem more like coding issues.
> 
> I guess that's what you were looking at. Next week [or whenever you get
> to it] no problem.

Yes, there were errors in three of the Windows x64 assembler code files
for broadwell_avx.

I have just corrected these in the repository and the build should now
succeed and pass the tests.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] msvc\mpir_config.py script errors

[Brian Gladman]

On 08/01/2019 15:15, dr vengy wrote:
> Hi,
> 
> Two questions:
> 
> Question #1:
> 
> Trying to build the latest mpir version from here:
> 
> https://github.com/BrianGladman/mpir
> 
> I'd like to add assembler optimised versions using the mpir_config.py script
> running python 3.7.2, however I get these errors:
> 
> 
> C:\Work\mpir-master\msvc>mpir_config.py
> Traceback (most recent call last):
>   File "C:\Work\mpir-master\msvc\mpir_config.py", line 21, in 
> from _msvc_project import Project_Type, gen_vcxproj
>   File "C:\Work\mpir-master\msvc\_msvc_project.py", line 5, in 
> from enum import IntEnum
> ImportError: No module named enum

Hi,

This is odd since the standard Python 3.7.2 distribution has the 'enum'
module, see here:

https://docs.python.org/3/library/enum.html#module-enum

On my system the file that provides this module is at:

C:\Program Files\Python37\Lib\enum.py

This suggests that there is an issue of some kind with your Python
installation.

Is it possible that there is an earlier version of Python that is also
instaled on your machine?  If so, it may be that your machine is set up
to use this version of Python even though you have Python 3.7.2
installed.  If this is what is happening, this article gives details of
how to solve this.

https://stackoverflow.com/questions/5087831/how-should-i-set-the-default-python-version-in-windows

But it may be easier to remove all versions of Python and reinstall only
Python 3.7.2.

Please let me know if I can help further with this.

> Question #2:
> 
> I've built the generic C dll_mpir_gc versions mpir.lib (import library) and 
> mpir.dll (external DLL). Does adding the import library mpir.lib cause issues 
> with LGPL? I could use LoadLibrary()/GetProcAddress() instead of mpir.lib but 
> that seems silly.

When you run an MPIR DLL using its stub library (mpir.lib), this creates
a link to the MSVC runtime libraries on the target machine. Provided
that these libraries are not distributed as a part of any MPIR
distribution (which they are not), I believe that this is consistent
with the system library exception within the LGPL.  I don't hence
_personally_ consider it necessary to avoid the use of the mpir.lib stub
library.

However, this is a purely personal opinion, not a legal one, since I am
not an expert on the legal niceties of the LGPL in relation to use of
Open Source software used on machines running Windows.

with my regards,

   Brian Gladman



-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] how to compile & install mpir + mpfr on fresh Windows 8 Visual Studio 2015 Express platform

[Brian Gladman]

On 16/11/2018 21:57, Jens wrote:
> Hello,
> 
> how can I install + compile the libs in Topic?

Hi Jens,

There is support for Visual Studio 2015 in my MPIR repository here:

   https://github.com/BrianGladman/mpir

The file mpir.pdf in the mpr\doc subdirectory gives details of how to
build MPIR with Visual Studio.

My build for MPFR is here:

   https://github.com/BrianGladman/mpfr/

but this only supports Visual Studio 2017. However, the VS1017 solution
will load in VS2015 and the build properties can then be manually edited
so that it will build (they will need to match those used to build MPIR).

The mpir and mpfr directories need to be put into a common directory and
the MPIR static library then has to be built.  The MPFR build can then
be completed.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR update announcement

[Brian Gladman]

On 29/09/2018 16:35, sisyph...@optusnet.com.au wro te:
> From: degski
> Sent: Sunday, September 30, 2018 12:44 AM
> To: mpir-devel@googlegroups.com
> 
>> The question is, why MPIR on linux and not GMP.
> 
> I've always thought that the only reason was that the MPIR licence was
> less restrictive than (or at least different from) the GMP licence.
> If that's not correct then I'd be interested to hear, though I don't
> really mind if this post of mine is ignored.
> 
> Note, too, that "our Swedish friend" has become a lot more amenable to
> Windows issues in recent years.
> Unfortunately, that amenability extends only to Windows builds of GMP
> that use mingw ports of gcc, and not to builds that use Microsoft
> compilers.

Hopefully Bill will tolerate a few posts here while we decide on the
details of future plans for MPIR on Windows.

My original development of a MSVC based build capability for GMP was
motivated by a number of personal uses that I had for this. This effort
evolved into MPIR and I have since continued to invest time and effort
into this because of its 'community' value even though my own personal
need for the capability has long since waned.

In consequence the only case for any continued development and
maintenance by me now depends on the desire in he community to have a
GMP equivalent that builds with native Windows tools (that is the
Microsoft and Intel compilers running on and targeting Windows).

My general view, judging on the emails that I get seeking advice, is
that there is still a demand for MPIR built with native Windows tools.

But, given that I will have to put continued effort into this, I would
like to hear the views of others here on the extent to which they
believe there is still a need for this.

Rest assured that I won't be offended by any answers that you might give
- I have no personal need or desire to keep investing in an MPIR (or
even GMP) build capability on Windows using native tools if there is no
longer a community need for this!

   with my kind regards to all,

  Brian Gladman

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR update announcement

[Brian Gladman]

On 29/09/2018 15:07, degski wrote:
> On Sat, 29 Sep 2018 at 01:43, 'Bill Hart' via mpir-devel
> mailto:mpir-devel@googlegroups.com>> wrote:
> 
> * Dr. William Hart's GitHub repository [1] will move to a continuous
> release model, whereby it is maintained in a continuous state of
> usability on Linux and OSX, as tested by Travis/Appveyor CI.
> 
> I'm probably just too dumb, but why is GMP not a viable solution on nix.
> I am so curious to this answer? Could you please elaborate on this question?
> 
> * Brian Gladman will distribute MSVC builds of MPIR from his GitHub
> account [2] and website [3].
> 
> Back to the old days then.

Yes, isn't nostalgia wonderful!

Thank you for your support over many years.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Can you just make us a Windows binary instead of source code?

[Brian Gladman]

On 18/08/2018 04:00, UZRNW SDRXG wrote:
> Whoops, here are the compiler logs! Can't seem to figure out how to edit
> my last post.
> 
> 1>-- Rebuild All started: Project: add-test-lib, Configuration:
> Release x64 --
> 1>EXEC : error : static library tests need 'mpirxx.lib'
> 1>C:\Program Files (x86)\Microsoft Visual
> Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(123,5):
> error MSB3073: The command "cd ..\..\..\build.vc  
> 1>C:\Program Files (x86)\Microsoft Visual
> Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(123,5):
> error MSB3073: check_config x64 Release 15
> 1>C:\Program Files (x86)\Microsoft Visual
> Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(123,5):
> error MSB3073: :VCEnd" exited with code -1.
> 1>Done building project "add-test-lib.vcxproj" -- FAILED.
> == Rebuild All: 0 succeeded, 1 failed, 0 skipped ==
> 
> 1>-- Rebuild All started: Project: mpz.addsub, Configuration:
> Release x64 --
> 1>EXEC : error : static library tests need 'mpirxx.lib'
> 1>C:\Program Files (x86)\Microsoft Visual
> Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(123,5):
> error MSB3073: The command "cd ..\..\..\build.vc  
> 1>C:\Program Files (x86)\Microsoft Visual
> Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(123,5):
> error MSB3073: check_config x64 Release 15
> 1>C:\Program Files (x86)\Microsoft Visual
> Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(123,5):
> error MSB3073: :VCEnd" exited with code -1.
> 1>Done building project "mpz.addsub.vcxproj" -- FAILED.
> == Rebuild All: 0 succeeded, 1 failed, 0 skipped ==

In order to test the MPIR static library builds you have to build both
mpir.lib (the C library) and mpirxx.lib (the C++ library).  As far as I
can tell these failures are being generated because the mpirxx.lib
project has not been built.

The problem with the missing Microsoft library (LIBCMT.LIB) is likely to
be caused by the use of a different Windows SDK to that set in the
default, which is currently 10.0.16299.0 (Windows 10 Creators Update).

If you know the Windows SDK you want to use, you can set this when you
run mpir_config.py.  An alternative is to edit this line:

   'windows_sdk':'10.0.16299.0'  # Windows 10 Creators Update

in the version_info.py file is the VS17 sub-directory (before you load
Visual Studio).  The SDKs for the various windows 10 updates are:

Windows 10:  10.0.14393.795
Windows 10 Creators Update   10.0.16299.0
Windows 10 latest (I think!) 10.0.17134.0

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Can you just make us a Windows binary instead of source code?

[Brian Gladman]

On 17/08/2018 21:59, Brett wrote:

> Hello, I really would like to use MPIR but I cannot after 1+ month of trying 
> for 200+ hours get anything to do anything. I know in Unix it's typical to 
> release source code, but on Windows nobody does it that way. 

Hi Brett,

I'm sorry that you have had issues in obtaining a suitable windows
binary of MPIR.  I wish that you had asked for help here before doing
all that  work since I feel sure that we could have steered you in the
right direction.

Please just compile your binary and upload the single .exe, .dll, or
.lib to the internet. Unlike Unix, Linux, and Mac, there is only one
version of Windows, so you only need to upload one binary file! It's a
lot easier on Windows! So please understand compiling other peoples'
source code on Windows in not standard, and as such you & us will only
ever have problems. We need to set up our computers to be exactly like
your computers in order for any source code to be worth anything.

The Windows build system for MPIR uses Microsoft Visual Studio for which
a free version is available.  The reason we don't offer binaries is that
there would have to be a lot of them since most users of MPIR want very
high speed and this means that the code has to be built for the specific
Intel processor on which a user wishes to run it.

But the Visual Studio build system is reasonably easy to use and a lot
of people are using it without difficulty so we should be able to guide
you through the process if you have run into trouble using it.

I know from Unix and Linux you guys obfuscate your OS and installation
methods in order to make it difficult and cool to use Linux. But
everyone else just wants to download 1 binary file and run it like you
know.. a normal person. You know how there's just 1 icon on my desktop
for Internet, and 1 icon for E-Mail, and 1 icon for Facebook. You need
to make 1 icon for MPIR! There is no need to have a .zip file with 4,172
files in it! Windows isn't like Linux, it's not hard to use! Windows can
just have 1 file!

As Bill has said we don't have the bandwidth to host the binaries as you
suggest.  But you are right that the current distribution approach is
one in which we put both the Linux and the Windows build into the same
distribution so each carries the unnecessary overhead of the other.  I
have a feeling that we should now offer the Linux/GCC and Windows/Visual
Studio builds as two separate distributions as this would greatly reduce
the size of the Windows distribution in particular.

If you are willing to try the Visual Studio build for MPIR, I feel sure
that I will be able to guide you through it (I am the developer and
maintainer of the build system on Windows).

   with my regards

  Brian Gladman

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: Can't Compile dll_mpir_gc in VS15

[Brian Gladman]

On 06/03/2018 09:20, sisyph...@optusnet.com.au wrote:
> 
> -Original Message- From: Brian Gladman
> Sent: Tuesday, March 06, 2018 6:54 PM
> To: mpir-devel@googlegroups.com
> Subject: Re: [mpir-devel] Re: Can't Compile dll_mpir_gc in VS15
> 
>> Hi,
>>
>> The log shows the following errors:
>>
>> mpz\pprime_p.c(119): error C2143: syntax error: missing ')' before ':'
>> mpz\pprime_p.c(119): error C2059: syntax error: ')'
>> mpz\pprime_p.c(119): error C2143: syntax error: missing ')' before ';'
> [ and more similar]
> 
> I've seen 'cl' throw errors like this on source files that 'gcc' finds
> to be quite acceptable.
> However, I don't have an exact match and Brian may well be right in
> pointing the finger at corrupted files.
> 
> For a simple demo of the sort of thing I'm thinking of, consider the
> following C program:
> 
> /**/
> #include 
> 
> int main (void) {
> 
> int a = 3;
> printf("%d\n", a);
> 
> int b = 6;
> printf("%d\n", b);
> 
> return 0;
> }
> 
> /***/
> 
> That builds fine for me on Windows with gcc, but using cl I get:
> 
> try.c(8) : error C2143: syntax error : missing ';' before 'type'
> try.c(9) : error C2065: 'b' : undeclared identifier
> 
> Maybe that's totally unrelated to what's happening here - but if file
> corruption is not the explanation, I'd be taking a close look at
> mpn_modexact_1_odd() because I think (unproven) that's where the problem
> is originating in all cases.
> 
> Cheers,
> Rob

Hi Rob,

I'll check this out.  Have you tracked down why cl fails when this happens?

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: Can't Compile dll_mpir_gc in VS15

[Brian Gladman]

On 06/03/2018 01:06, Oluseye Akomolede wrote:
> Good evening,
> 
> Here is the log output combined with the log folders that Visual Studio
> 2015 creates.

Hi,

The log shows the following errors:

mpz\pprime_p.c(119): error C2143: syntax error: missing ')' before ':'
mpz\pprime_p.c(119): error C2059: syntax error: ')'
mpz\pprime_p.c(119): error C2143: syntax error: missing ')' before ';'

mpz\kronzu.c(78): error C2143: syntax error: missing ')' before ';'
mpz\kronzs.c(82): error C2143: syntax error: missing ')' before ';'
mpz\kronuz.c(118): error C2143: syntax error: missing ')' before ';'
mpz\kronsz.c(126): error C2143: syntax error: missing ')' before ';'

mpz\jacobi.c(158): error C2143: syntax error: missing ')' before ';'
mpz\divis_ui.c(71): error C2143: syntax error: missing ')' before ';'

which indicates that these files (and maybe others as well) have become
corrupted in some way. You need to find out why this has happened since
it could be a problem with the original download or a problem on your
computer such as, for example, disc errors.

I would suggest that you start again using a new download of MPIR.  If
this fails again in the same way you need to discover how the MPIR files
are becoming corrupted.

with my regards,

  Brian Gladman

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Broadwell support

[Brian Gladman]

On 30/01/2018 14:31, 'Bill Hart' via mpir-devel wrote:

[snip details]

In terms of work that needs to be done from a Windows perspective:

1. I have added two new functions to the MPIR API (as discussed
recently) and I need to offer documentation for these to be added to the
MPIR documentation.

2. Dima has suggested the use of a GIT sub-module to tidy up the Windows
build files by putting them in a single directory (msvc).  I have now
done most of the work needed to provide for this change but in doing so
I have found an issue in Visual Studio 2017 that may hold up the
release.  I have raised the issue with the Microsoft Visual Studio team
who are now investigating it.
I think I have added all Jen's Broadwell code to the Windows build but I
would appreciate a warning when new assembler code is added to MPIR so
that I can check this.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

[Brian Gladman]

On 24/01/2018 16:07, 'Bill Hart' via mpir-devel wrote:

[snip]
> On a more optimistic note, the work that Jens Nurmann and I have done in
> adding new assembler code for recent machine architectures is available
> for those who are willing to work with the repository version of MPIR.
> 
> And it may well make sense to add the new functions to my repository
> anyway as it will at least mean that I can keep the repository versions
> of both MPIR and FLINT for Windows x64 in a fully working state (the
> FLINT changes needed are very limited as discussed earlier).
> 
> 
> Was all Jens' Broadwell optimisation committed. The last I recall we
> were waiting for someone with a Broadwell to test and see which
> functions were faster than the current ones. This would have had to be
> done on a Linux system, since it isn't possible to get reliable timings
> on a Windows box, unfortunately.
> 
> Or are you only talking about Skylake and Nehelem, which I think is in
> MPIR-3.0.0.

I was thinking about Broadwell and Skylake but couldn't remember what
got in to MPIR-3

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

[Brian Gladman]

On 24/01/2018 12:15, 'Bill Hart' via mpir-devel wrote:

[snip]
> What has just occurred to me is that we can arrive at a 'perfect' MPIR
> integer API by reversing how the doubles and integers are returned:
> 
> mpir_si mpz_get_2exp_d(double *r, mpz_srcptr src)
> mpir_si mpf_get_2exp_d(double *r, mpz_srcptr src)
> 
> If these returned a 64 bit integer and I had code like:
> 
> long s = mpz_get_2exp_d(r, src);
> 
> would this automatically cast down to the shorter length integer? I'm
> not sure I see why this is better than the current situation?

The fix doesn't do a lot here but it helps in two other situations.

With what we have now, when a 64-bit value is stored via a pointer into
a 32-bit location, the upper 32-bits will overwrite data in adjoining
locations and cause erroneous results and/or crashes.

Also, when a 32-bit value is stored via a pointer into a 64-bit
location, the upper 32-bits won't be overwritten so whatever was in the
top 32-bits will remain causing the value to be incorrect.

These bugs turn up not infrequently on Windows x64 and it would be good
to remove them.

> Well, it is better in the sense that it gives the full 64 bits, which we
> will obviously use in Flint. But does it make writing code any easier?

Yes in that it will make it easier to write code that doesn't contain
the sort of bugs that we are discussing.

> Also, any existing code will not be using these and will have to be
> rewritten. Not a big problem for Flint, as you have noted, but maybe for
> other systems?

Not immediately since I envisage these as functions that are additions
to, rather than replacements of, the existing functions.  We might, of
course, remove the older ones later.

> As the MPIR Windows developer/maintainer, moving to an MPIR API that is
> pure in respect of integer length is compelling, especially so as it is
> not hard to achieve at the code level.
> 
> But it would seem that making this change won't be possible unless we
> can find a volunteer to do the work that this requires for Linux/Unix
> and for delivering new MPIR distributions.
> 
> I very much doubt we will find one. I've been calling for people to
> contribute for years. No one has stepped forward and stuck with it.
> 
> It requires a very skilled individual, most of whom are busy with other
> projects.

> Leaving FLINT on Windows x64 (and other applications that depend on it)
> reliant on old versions of MPIR and GMP would effectively mean that it
> would progressively die on Windows since it would not be able to take
> advantage of the work that Jens Nurmann and I have done in adding
> assembler code support for recent Intel processor architectures.
> 
> I think MPIR will die on all platforms, in time. The community just
> doesn't have any interest in it. Were the interest there, we'd know by now.
> 
> People only seem keen on fixing it if it stops building. They don't care
> about performance, adding functionality or dealing with tickets that
> aren't immediately breaking their code.

> It's especially a shame that the work Jens put in still sits in limbo.
> But I just don't have the time to do the testing, profiling and
> integration required. There's a week of work for someone who knows what
> they are doing, or a months for someone who is new to MPIR but otherwise
> very skilled. 

On a more optimistic note, the work that Jens Nurmann and I have done in
adding new assembler code for recent machine architectures is available
for those who are willing to work with the repository version of MPIR.

And it may well make sense to add the new functions to my repository
anyway as it will at least mean that I can keep the repository versions
of both MPIR and FLINT for Windows x64 in a fully working state (the
FLINT changes needed are very limited as discussed earlier).

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

[Brian Gladman]

On 23/01/2018 21:20, 'Bill Hart' via mpir-devel wrote:
> 
> 
> On 23 January 2018 at 22:13, Brian Gladman  <mailto:b...@gladman.plus.com>> wrote:
> 
> On 23/01/2018 20:00, 'Bill Hart' via mpir-devel wrote:
> > Hi Brian,
> >
> > I believe the problem is that our LLL code actually relies on a 64 bit
> > exponent on Windows 64 (in practice, not just in theory), but GMP (or
> > the compatibility function) only returns a 32 bit one.
> 
> Ah, OK.  So basically FLINT won't work on Windows x64 because longs are
> 32-bits and FLINT expects longs to be 64-bits.
> 
> So FLINT on Windows x64 won't work at all with current versions of GMP
> since longs are 32-bits. And it won't work with MPIR 3 because we have a
> function that uses 32 bit longs in its interface.
> 
> But could we not have a 'compatibility define' in MPIR that makes the
> function work for 64-bit longs when needed?
> 
> I guess that's an option. It won't fix the GMP issue for us either way.

I was pondering this issue further last night and it occurred to me that
there is a solution that I wish I had thought of earlier.

The introduction of the typedefs mpir_ui and mpir_si for unsigned and
signed integers in the MPIR API was an almost complete solution to the
Windows x64 problem caused by its use of 32-bit integers.  It worked
almost everywhere as a result of automatic promotion rules except for
just two functions that returned integers via pointers:

double mpz_get_d_2exp(mpir_si *exp2, mpz_srcptr src)
double mpf_get_d_2exp(mpir_si *exp2, mpf_srcptr src)

These caused a number of bugs since 64-bit values would be written into
32-bit ones corrupting adjoining memory and 32-bit values would be
written to 64-bit ones leaving 32-bits undefined.

What has just occurred to me is that we can arrive at a 'perfect' MPIR
integer API by reversing how the doubles and integers are returned:

mpir_si mpz_get_2exp_d(double *r, mpz_srcptr src)
mpir_si mpf_get_2exp_d(double *r, mpz_srcptr src)

By introducing these two functions we will have no more 32/64-bit
trouble on Windows x64 provided these new functions are used in place of
the old ones.  And, if the FLINT code is a typical example, the work
needed to switch to these new functions will be small at least at the
code level.

This still leaves the problem in GMP but FLINT has a GMP compatibility
layer where these two new functions could be derived from their GMP
equivalents or implemented directly.

As the MPIR Windows developer/maintainer, moving to an MPIR API that is
pure in respect of integer length is compelling, especially so as it is
not hard to achieve at the code level.

But it would seem that making this change won't be possible unless we
can find a volunteer to do the work that this requires for Linux/Unix
and for delivering new MPIR distributions.

Leaving FLINT on Windows x64 (and other applications that depend on it)
reliant on old versions of MPIR and GMP would effectively mean that it
would progressively die on Windows since it would not be able to take
advantage of the work that Jens Nurmann and I have done in adding
assembler code support for recent Intel processor architectures.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

[Brian Gladman]

On 23/01/2018 21:20, 'Bill Hart' via mpir-devel wrote:
> 
> 
> On 23 January 2018 at 22:13, Brian Gladman  <mailto:b...@gladman.plus.com>> wrote:
> 
> On 23/01/2018 20:00, 'Bill Hart' via mpir-devel wrote:
> > Hi Brian,
> >
> > I believe the problem is that our LLL code actually relies on a 64 bit
> > exponent on Windows 64 (in practice, not just in theory), but GMP (or
> > the compatibility function) only returns a 32 bit one.
> 
> Ah, OK.  So basically FLINT won't work on Windows x64 because longs are
> 32-bits and FLINT expects longs to be 64-bits.
> 
> So FLINT on Windows x64 won't work at all with current versions of GMP
> since longs are 32-bits. And it won't work with MPIR 3 because we have a
> function that uses 32 bit longs in its interface.
> 
> But could we not have a 'compatibility define' in MPIR that makes the
> function work for 64-bit longs when needed?
> 
> 
> I guess that's an option. It won't fix the GMP issue for us either way.
> 
> The problem of course is that an mpz (and hence an fmpz) can be 2^31
> words, not bits. Therefore the number of bits in such an exponent can be
> larger than 2^32.
> 
> Any solution requires non-trivial work, anyway. And unfortunately I have
> no time for such things these days. I can only merge patches into MPIR.
> That's all I have time for. The community is suppose to be taking over
> the job of handling releases, etc. But so far there haven't been any
> volunteers.

At a code level the changes needed to fix this are not large if we do it
by adding two functions in MPIR in parallel with the existing ones - say
mpz_get_d_2exp_si() and mpf_get_d_2exp_si().  This would need changes in
at most four lines in FLINT and the work in MPIR is not large (I would
be happy to do it).

But I do understand the wider cost in doing releases etc.  Nevertheless
it seems a pity to give up on FLINT on Windows 64 when an MPIR based fix
looks to be feasible.

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

[Brian Gladman]

On 23/01/2018 20:00, 'Bill Hart' via mpir-devel wrote:
> Hi Brian,
> 
> I believe the problem is that our LLL code actually relies on a 64 bit
> exponent on Windows 64 (in practice, not just in theory), but GMP (or
> the compatibility function) only returns a 32 bit one.

Ah, OK.  So basically FLINT won't work on Windows x64 because longs are
32-bits and FLINT expects longs to be 64-bits.

So FLINT on Windows x64 won't work at all with current versions of GMP
since longs are 32-bits. And it won't work with MPIR 3 because we have a
function that uses 32 bit longs in its interface.

But could we not have a 'compatibility define' in MPIR that makes the
function work for 64-bit longs when needed?

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

[Brian Gladman]

On 23/01/2018 12:28, 'Bill Hart' via mpir-devel wrote:

> Yes, but Flint itself relies on the old version, and no one has time to
> fix it.

Hi Bill,

I must be missing something here since this makes no sense to me.

The function mpf_get_d_2exp() is mentioned only once in FLINT2 and there
is no difference in the calls to MPIR and GMP. So this function doesn't
seem to be a problem.

There are three calls to mpz_get_d_2exp in FLINT2:

In dlog.c:
--
#if defined(__MPIR_VERSION)
slong e;
#else
long e;
#endif

s = mpz_get_d_2exp(&e, COEFF_TO_PTR(*x));
--

In get_d_2exp.c:
--
#if defined(__MPIR_VERSION)
   return mpz_get_d_2exp(exp, COEFF_TO_PTR(d));
#else
   long exp2;
   double m = mpz_get_d_2exp(&exp2, COEFF_TO_PTR(d));
   *exp = exp2;
   return m;
#endif
--

In both cases changing:

#if defined(__MPIR_VERSION)

to

#if __MPIR_VERSION < 3

fixes the issue.

Are you really saying that no one has the time to do this?

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

[Brian Gladman]

On 23/01/2018 11:58, 'Bill Hart' via mpir-devel wrote:
> Hi Brian,
> 
> The history of the Flint issue is in this ticket here:
> 
> https://github.com/wbhart/flint2/issues/338
> 
> I'm not sure if MPIR Windows users will actually *want* this fixed. But
> unfortunately, Flint relies on the old semantics, and can't be easily
> fixed, I think.

Hi Bill,

Since, in respect of the two functions involved, the current versions of
MPIR and GMP now use the same semantics, the GMP compatibility layer
must have a fix for this.

Can this fix not be applied to the MPIR interface?

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

[Brian Gladman]

On 23/01/2018 09:59, 'Bill Hart' via mpir-devel wrote:
> Hi all,
> 
> This is just a brief note to let the community know that as of
> MPFR-4.0.0, Flint no longer supports the latest versions of MPIR or MPFR
> on Windows.
> 
> MPFR-4.0.0 is no longer compatible with MPIR-2.7.2 and Flint is no
> longer compatible with MPIR-3.0.0. I doubt that anyone wants to fix any
> of these issues.

Since the MPIR (repository) and MPFR (version 4) are fully compatible on
Windows, can you say more about the problems in Flint that mean these
versions can no longer be used?

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] gmp source/include compatibility?

[Brian Gladman]

On 20/09/2017 11:30, Francis Andre wrote:
> Hello
> 
> I am porting on Windows a Linux application that is a consuler of the GNU gmp 
> library. Googling for GMP on Windows, I did not find any realistic GMP 
> packaging on Windows except the mpir library, which in my understandin is a 
> fork fo the GNU gmp library. So I choose to use the mpir librairy to replace 
> the GNU gmp one. But the include interface is different. The ported 
> application is referring the include gmpxx.h which is in fact the mpir.h.
The main include files in GMP are  for use in code written in C
and  for use in code written in C++.

The equivalent files in MPIR are  and  respectively.

> Thus can this 'mpir.h' include be renamed 'gmpxx.h' or copied to 'gmpxx.h' so 
> that a full compatibility be insured. By the way, the head of mpir.h is as 
> below
> 
> /* gmpxx.h -- C++ class wrapper for GMP types.  -*- C++ -*-
> 
> Copyright 2001, 2002, 2003, 2006, 2008, 2011, 2012 Free Software Foundation

This file appears to be the C++ interface to GMP, not a renamed 

Renaming  as  won't work as this will only provide the
C interface to MPIR whereas any code that uses  is presumably
expecting to use the C++ interface in .

To use MPIR as a replacement for GMP in C and C++ code you need to
include  instead of  and  instead of .

If you wish to do this by renaming files instead of changing the include
file names, you will need to rename  to .

But  does not need to be renamed (and should not be) because
MPIR already provides a copy of  renamed as .

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR 3.0.0 on VS15

[Brian Gladman]

On 24/05/2017 18:05, Russell Wallace wrote:
> Oh! No, I'm using Windows 7, so the next release won't help with that
> either. I don't suppose you'd be willing to change the build script so
> that it works on any version of Windows? (As far as I know, the usual
> ways of creating build scripts with Visual C++ don't depend on a
> particular version of Windows.)

Hi Russell,

In my MPIR repository at:

https://github.com/BrianGladman/mpir

I have modified the build generator (mpir_config.py) so that the Windows
SDK for the generated build can be set when the scrript is run.

So to build Visual Studio solutions for Visual Studio 2017 (vs15) with
the Windows 7.1 SDK you would run it from the command line as follows:

>> mpir_config.py 15 7.1

You might like to try this to see if it solves your problem.

The SDK you choose must, of course, be installed on your build machine.

   best regards,

  Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR 3.0.0 on VS15

[Brian Gladman]

On 24/05/2017 18:05, Russell Wallace wrote:

> Oh! No, I'm using Windows 7, so the next release won't help with that
> either. I don't suppose you'd be willing to change the build script so
> that it works on any version of Windows? (As far as I know, the usual
> ways of creating build scripts with Visual C++ don't depend on a
> particular version of Windows.)

Hi Russell,

I could change the Python build generator (mpir_config.py) to allow the
input of the SDK version to be used if that would help.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR 3.0.0 on VS15

[Brian Gladman]

On 24/05/2017 18:05, Russell Wallace wrote:
> Oh! No, I'm using Windows 7, so the next release won't help with that
> either. I don't suppose you'd be willing to change the build script so
> that it works on any version of Windows? (As far as I know, the usual
> ways of creating build scripts with Visual C++ don't depend on a
> particular version of Windows.)

When you ask to retarget, it should detect what is available on your
system so you can select the SDK accordingly.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR 3.0.0 on VS15

[Brian Gladman]

On 24/05/2017 15:52, Russell Wallace wrote:

> Ack, sorry, pressed send by accident!
> 
> Anyway as I was saying, happy to see the release of MPIR 3.0.0,
> particularly for the VS15 support. I tried to build it just now with
> VS15 aka VS2017 community edition, 64-bit everything:

Hi Russell,

This is the problem:

> error MSB8036: The Windows SDK version 8.1 was not
> found. Install the required version of Windows SDK or change the SDK
> version in the project property pages or by right-clicking the solution
> and selecting "Retarget solution". [C:\mpir\build.vc15\lib
> _mpir_core2\lib_mpir_core2.vcxproj]

MPIR is still set for the Windows 8.1 SDK by default but you are, I
assume, using a Windows 10 SDK.

After loading MPIR, you can select the solution in the solution
explorer, select "Retarget solution" and then select the SDK you want to
use (you need to do this for the tests as well).

I plan to default to Windows 10 in the next release.

   best regards,

 Brian Gladman

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] mpf_fits_uXXX returns false for -0.9

[Brian Gladman]

On 14/05/2017 03:09, Alex Dyachenko wrote:

> Now that we're at 3.0.0 and support GMP 6.0.0, should this issue be
> activated?

I did make the change to achieve GMP compatibility in my repository in
2014 but I reverted it as I wasn't clear that we wanted to make the
change at the time.

So, yes, we surely need to make this change now, which I will do if we
agree.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Failures reported by run-tests.py

[Brian Gladman]

On 30/03/2017 11:05, david Wohlferd wrote:
> Sorry for the delayed response.  Google never notified me that you had
> responded.  I was thinking bad thoughts about you, but then realized I
> should at least check.  And there you were.

Thanks for that test, David, which allowed me to track the bug down.

This is an assembler code bug which occurs only on Windows and only on
the sandybridge and sandybridge_ivybridge builds.  I have corrected the
bug in my MPIR repository at:

   https://github.com/BrianGladman/mpir

For those that need a quick fix, edit the file at:

   mpir\mpn\x86_64w\sandybridge\mullow_n_basecase.asm

and change line 78:

ja .1

to:

jae.1

I'm afraid this bug is down to me alone, for which I apologise.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Failures reported by run-tests.py

[Brian Gladman]

On 28/03/2017 00:29, david Wohlferd wrote:
> I've just started using mpir.  Following the instructions, I built the
> library for my hw, then ran the tests to ensure everything was working. 
> Apparently not everything is working.

Hi David,

> Testing MPIR Static Library (lib_mpir_sandybridge_ivybridge) in
>  Configuration
>  Test skipped, replacing localeconv/nl_langinfo doesn't work

This one can be ignored - it is the result of a difference between the
way this feature works on *nix and Windows.

mpn.mullowhigh : ERROR ( 255  )
>  mpn_mullow_n error 2

Although I have not yet checked whether mpz.pown and mpz.powm_ui depend
on mpn_mullow_n, the mpn* routines are low level routines on which the
higher level routines depend so it seems likely that this error is also
the cause of the other errors you are seeing.

So we need to track this one down first and here it would be useful to
know whether this is error depends on assembler code by testing the
build when using only generic C code.  I would hence be most grateful if
you could build and test the lib_mpir_gc version of the library to see
if this error persists.

 with my regards,

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Mpir 3.0.0 seems to be about 8% slower than 2.7.2 for small floats (1-4 limbs)

[Brian Gladman]

On 04/03/2017 20:57, kesse...@schema.de wrote:

> first of all, thanks for all the great MPIR work! I've been using it for 
> about 4 years to compute visually compelling deep Mandelbrot zoom videos.
> 
> Yesterday I've downloaded 3.0.0 and compiled it using VS 2015 U3 on an Intel 
> Core i7 6900K (8 cores, Broadwell) on Windows 10 64.
> 
> Unfortunately, 3.0.0 seems to be slower than 2.7.2 by about 8% when small 
> floats are used. By small floats I mean a precision of up to 256 bits (4 
> limbs on x64).
> 
> Compilation worked flawlessly for all of the 10 architectures I've selected. 
> Just to make sure Visual Studio updates are not the source of the problem, I 
> also recompiled the 7 architectures I've been testing with 2.7.2.

[snip details]

Hi Marcus,

As the maintainer of the Windows builds for MPIR, I would like to thank
you for your work on this issue.  Even though it was not the focus of
your email, I much appreciate your confirmation that the Windows build
process is working as intended.

Turning to the performance issue, i don't have much to add to what you
and Bill have said.  My first thought was that tuning has been messed up
but it cannot be this since the tuning files for the two versions are
identical.

As Bill has said, tuning on Windows is not very stable so we simply use
the tuning values for the *nix/GCC versions.  But this too cannot
explain the difference as it also applies to both versions.

One thing that I would like to see, if possible, is the result of
running the MPIR benchmark code on your system for the two MPIR
versions.  The benchmark covers various internal routines and might show
us whether particular routines are at fault.  It would also be a useful
second look at the issue.

   with my regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: Help needed for upcoming release

[Brian Gladman]

On 09/02/2017 16:54, 'Bill Hart' via mpir-devel wrote:
> Thanks Brian. I am on leave until next week but will get straight onto
> this when I return to work.

I have just done the same for the mpn_sizeinbase routine (which was in
our codebase but not declared as such).

   regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: Help needed for upcoming release

[Brian Gladman]

On 01/02/2017 15:41, 'Bill Hart' via mpir-devel wrote:
> I've made a milestone to track which tickets are open and unassigned.
> 
> https://github.com/wbhart/mpir/milestone/2

Hi Bill,

I have done most of this item (from the above list):

   Add new GMP limbs functions #101

But I have not done any of *nix/GCC build aspects needed for this item.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Help needed for upcoming release

[Brian Gladman]

On 01/02/2017 11:43, 'Bill Hart' via mpir-devel wrote:

> As of today, MPIR no longer has someone paid to work on it, which means
> that it goes back to being community maintained.

I have checked/responded to the Windows issues as follows:

> #178 Unnecessary WIN64_GCC_PROC in mul_basecase.asm

As far as I can tell this is not an issue with MPIR.  The poster appears
to be using MPIR assembly code with another GMP distribution that does
not use our Visual Studio build files.

> #176 ERROR: static library tests need 'mpirxx.lib'

This is not a build failure - the poster has not realised that there are
two static libraries for MPIR -one for C and one for C++.

> #175 Conflict addmul_2/redc_2 with _gmpn_addmul_2

This is probably caused by an update of the assembly code without a
corresponding update of the VS build files.  The issue is not present
When the build files are updated.

> #160 Compiling error

This error is not caused by any issue in the MPIR build.

> #159 mpz.fac_ui : ERROR with x64 Release on Visual Studio 2015

I cannot reproduce this test failure.

-

As far as I know the Visual Studio builds are all in a working state.

But there are several Windows issues that need attention before we
release as follows:

1. I need to add GCC tuning data to the Windows directories that have
new assembler code in them.  I would be grateful to know when tuning has
been completed for the new assembler code so that I can do this.

2.  I need to add build files for Visual Studio 2017, which will almost
certainly be released before the end of February.

3. I need to tidy up the Visual Studio build files into a form that is
suitable for the actual release.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Mpir Windows build with --enable-gmpcompat?

[Brian Gladman]

On 18/12/2016 21:53, imbacen wrote:
> I didn't find a user mailing list so this will have to do. 
> 
> Per Mpir documentation, using --enable-gmpcompat switch when running 
> ./configure will produce gmp.lib and gmp.h for compatibility. There is no 
> mention of how to do that in Windows build though. How to do this in the 
> Visual Studio project? I assume the flag does not simply rename the target 
> but does some other stuff behind the scenes.

As far as I am aware, all that is done by this option is to produce
duplicates of the mpir output files named 'gmp' instead of 'mpir'. But I
might be wrong as I know very little about the *nix build processes

However, there is no equivalent of this for the Visual Studio builds -
if you need such files you have to rename them yourself.

   with my regards,

  Brian



-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Website down

[Brian Gladman]

On 02/10/2016 14:18, The Survivor wrote:
> Hello everyone,
> 
> I discovered MPIR two days ago, however, mpir.org seems to be down since 
> approximatively September, the 25 (from google archive).
> 
> Anynone has informations ?

While the MPIR website is down, you can get MPIR source code from my
repository at:

   https://github.com/BrianGladman/mpir


  Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Microsoft Visual Studio 2015, newbie problems with build errors

[Brian Gladman]

On 04/08/2016 12:25, Robert Steed wrote:
> I'm a newbie. In Microsoft Visual Studio Community 2015 running on Windows 10 
> x64, I installed "mpir-2.7.2\build.vc14\lib_mpir_gc", WIn32 Release config, 
> as per instructions in "mpir-2.7.2.pdf", and all the tests in 
> "mpir-2.7.2\build.vc14\mpir-tests" were successful. I wrote a tiny first 
> program which calls mpz_set_si(), included "mpir.h", got this build error:
>   Error   LNK2001 unresolved external symbol ___gmpz_set_si
> So I included "gmp-impl.h", even though that isn't mentioned in 
> "mpir-2.7.2.pdf". Now I get this build error:
>   Error   C1189   #error:  no data available for this limb size in 
> perfsqr.h
> 
> What is that about, and how do I get up and running? Is there some resource 
> for beginners anywhere with comprehensive instructions or tutorials on how to 
> use MPIR? How is a beginner supposed to learn how to use MPIR?

Hi Robert,

To use MPIR in a Visual Studio project you have to do two things. First
you have to include "mpir.h" as you have done. Second, you have to add
the relevant MPIR library to your project. It seems likely that you have
not done the latter.

Assuming that you are using the static library (mpir.lib), you need to
add this to your solution by using the Visual Studio 'Properties'
dialogue (an option when you right click on your solution in the
Solution Explorer).  You need to find the location of the library (e.g.
lib\win32\release\mpir.lib) and add it to the 'Linker|Input|Additional
Properties' item.

Alternatively, right click on your solution in the Solution Explorer,
select 'Add|Existing item', navigate to the library in the file dialogue
and select it to add it to your project.

I hope this helps, if not just get back to me and I will see what I can
do to help further.

   Brian








-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Length of clz_tab?

[Brian Gladman]

On 31/07/2016 14:16, 'Bill Hart' via mpir-devel wrote:
> If it is causing problems then we should make the change. It's just a
> table for counting leading zeros. On most platforms an assembly
> instruction is used for doing this. But on Windows 64 the lack of inline
> assembly probably means it is using the C fallback.

Thanks Bill,

I have changed it in my repository.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] sqr_basecase.asm fails to compile in win32/release tune project

[Brian Gladman]

On 21/05/2016 17:06, terry_ly...@lyonstech.net wrote:

> Hi Guys, I don't know how to interpret this but when I build the tune
> project for win32, the sqr_basecase.asm file fails to compile with many
> warnings but also several errors. Probably this is just because
> it should be excluded in 32 bit? Since tune is so unreliable in 64bit,
> (It only works about one time in 5!) I wondered if this was part of the
> issue. In any case I would like good tuning choices for the 32bit gc
> optimised code on a modern powerful machine. I use a haswell chip. I was
> surprised by the differences between the choices provided and the ones
> selected by tune for x64 for this hardware. No real idea if they change
> things in practise, but I guess they will?

I am surprised that you even get close to building the MPIR
tuning/testing apps on Win32 since I have not been supporting these for
the last three years.  I only maintain them on X64.

As you suggest, the sqr_basecase.asm should be excluded for win32
builds.  But I would be rather surprised if that is the only problem you
face!

> By the way, I understand the limitations of your resource and really
> appreciate the existence of MPIR as is, but I still think win32 is
> important, I need code that works regardless of platform as well as a
> best speed x64 version, I appreciate the C interfaces and have used old
> dlls for a very long time (never using the formatting/C++ aspects for
> stability reasons); my current interest comes because I am currently
> upgrading because of a new platform. 

You may, if we are lucky, see some new assembler code for current Intel
architectures later in the year.

   Brian


-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] fix: 2.7.2 x64 lib debug build with msbuild vs2015 fails

[Brian Gladman]

On 21/05/2016 14:09, terry_ly...@lyonstech.net wrote:
> msbuild with the recommended settings:
>  
> [pyk3] C:\Users\\mpir-2.7.2\build.vc14>msbuild haswell lib x64 debug 
> +tests > build_haswell_lib_x64_debug.log
> 
> fails for me complaining that /O2 and /RTC1 are incompatible -- as indeed 
> they are:

Hi Terry,

Yes, this is a bug that has been fixed in my MPIR repository.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MSBuild fails for 10 tests

[Brian Gladman]

On 21/05/2016 13:24, terry_ly...@lyonstech.net wrote:
> Version 2.7.2 Release x64 lib for Haswell using VS2015 enterprise msbuild in 
> an admin command window.
> 
> Have just built this library and run the tests through the python script. The 
> tests reported that all built tests succeeded, however it reported that 10 
> tests were not built.
> 
> Build failure for mpn.dc_bdiv_q
> Build failure for mpn.dc_bdiv_q_n
> Build failure for mpn.dc_bdiv_qr
> Build failure for mpn.dc_bdiv_qr_n
> Build failure for mpn.inv_div_q
> Build failure for mpn.inv_div_qr
> Build failure for mpn.inv_div_qr_n
> Build failure for mpn.sb_bdiv_q
> Build failure for mpn.sb_bdiv_qr
> Build failure for mpn.tdiv_qr

Hi Terry,

I am sorry that you are having problems but I fear that I cannot
duplicate your problems here.  I was hopeful that I could help as my
setup is identical to yours (VS2015 Enterprise). But I downloaded a
clean version of MPIR 2.7.2, configured a Haswell build and built the
library and the tests without any problems at all.

There is a potential issue in building the tests that leads to a number
of build failures when they are built but it doesn't match your report.

Typically VS2015 will buid a number of the tests in parallel but this
means that the add-test-lib (the common library for the tests) and a
number of the tests are built at the same time. But if the library build
has not completed before the build of a test, the latter will fail
because the library it needs is not yet available.

There are several fixes. Just run the build of the tests again; manually
buid add-test-lib first; turn off parallel build in VS2015.  But, as I
say, this does not seem to be the problem you are seeing

> It seems to me that the key is the following style warning which appears 10 
> times as well:
> 
> 
> "C:\Users\\mpir-2.7.2\build.vc14\mpir-tests\mpn.dc_bdiv_q_n\mpn.dc_bdiv_q_n.vcxproj"
>  (default target) (1) ->
> (DoLinkOutputFilesMatch target) -> 
>   C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1189,5): 
> warning MSB8012: 
> TargetPath(C:\Users\\mpir-2.7.2\build.vc14\mpir-tests\mpn.dc_bdiv_q_n\..\..\x64\Release\mpn.dc_bdiv_q_n.exe)
>  does not match the Linker's OutputFile property value 
> (C:\Users\\mpir-2.7.2\build.vc14\mpir-tests\x64\Release\mpn.dc_bdiv_q_n.exe).
>  This may cause your project to build incorrectly. To correct this, please 
> make sure that $(OutDir), $(TargetName) and $(TargetExt) property values 
> match the value specified in %(Link.OutputFile). 
> [C:\Users\\mpir-2.7.2\build.vc14\mpir-tests\mpn.dc_bdiv_q_n\mpn.dc_bdiv_q_n.vcxproj]
> 
> 7 Warning(s)
> 0 Error(s)
> 
> Time Elapsed 00:00:00.86
> 
> Related to this (I think), while almost all of the code compiles silently, a 
> few modules produce copious noise about 32<->64 bit issues. 
These are very disconcerting to a user. It is hard for an inexperienced
user to see if the underlying code produces the warnings or
if it is just the tests that have issues.

Yes, sadly there are hundreds if not thousands of these.  We just don't
have the time to go through an awful lot of code to remove them.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] bug: run-tests.py fails

[Brian Gladman]

On 21/05/2016 12:54, terry_ly...@lyonstech.net wrote:
> Hi, In mpir.2.7.2. If I run run-tests.py from the command line when the focus 
> is already in the subfolder mpir-tests of build.vc14, it fails - the code 
> executes
> 
> cw, f = os.path.split(__file__)
> os.chdir(cw)
> 
> and fails! because cw = ''

Hi Terry,

That's a bit naughty of Python, returning a directory that fails when
used in a change directory request!

As you say, an easy fix, thanks for finding it.

  Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: C++ wrappers don't support 64-bit integers (size_t, long long int) on Win64

[Brian Gladman]

On 21/05/2016 17:36, terry_ly...@lyonstech.net wrote:
> 
> 
> On Monday, 24 October 2011 20:31:02 UTC+1, Cactus wrote:
> 
> You are right - size_t is supposed to be 64-bits on Windows x64.
>  But to get this behaviour, you have to define _WIN64 during the
> build process.
> 
> I have been caught by this so many times because  _WIN64 is supposed
> to be a predefined macro, onr that is automatically defined for
> 64-bit builds.  
> 
> But, as far as I can see, it has to be user defined.
> 
>Brian
> 
> 
> Sorry this is late in the day, but surely defining _Win64 is required
> internals to getting an x64 build?  In Intel MKL at least ILP64 is the
> usual notation for 64bit integers on x64 - while LP64 refers to using 32
> bit integers in an x64 environment. This is orthogonal to the language
> used in this thread.
> 
> At the risk of opening old discussions, one point I never understood is
> the trouble over 32bit and 64 bit integers in GMP/MPIR. It seems this is
> still (2016) causing trouble in some parts of the testing code. The mkl
> solution is one way, with distinct ILP64, LP64, WIN32 libraries; but
> ?unless I am missing something, it seems that all MPIR wanted was
> integers that are 64 bit on 64 bit machines and 32 bits on 32 bit
> machines. Surely this configuration is always available from the
> original unix code via a global replace of unsigned int by std::size_t
> and int by std::ptrdiff_t in .  As far as I can see this is
> truly system independent and standard compliant.

Hi Terry,

As I am sure you know, there is an enormous amount of code in MPIR,
which for the most part works well in a *nix environment.  We would not
want to have separate code bases for *nix/GCC and Windows/MSC so doing a
global replace would mean that code that works well on *nix/GCC would be
subject to significant changes that would in all probability lead to
quite a few bugs that would have to be tracked down and fixed. A lot of
this code is very mature and has worked without problems for a long time
so it really seems sensible to take the line that 'if it isn't broken
don't fix it.

> If one wants precise bit length integers then int32_t and int64_t seem
> the way to go - as they are (rather elegantly) only defined in the
> standard if the OS actually has those lengths (which it may not since a
> byte may not be 8 bits).
> 
> The subtle flaws referred to in MPIR documentation really come neither
> from windows or unix but from using a non-standard defined behaviour of
> int when really this is not necessary (although understandable). The
> type int should probably not appear anywhere in the code of MPIR except
> for input and output to other api's (such as output) where it should be
> checked for overflow using safeint<> or similar. I worry that builds (at
> least of tests) still show some 64bit<->32bit conversion warnings. I
> suppose now that the underling library code is really OK. I certainly
> believe/assume that if I use strings to serialise and pass long integers
> between machines in MPI there is no danger of lost information. In fact
> I think MPIR::GMP is a great tool.

The code is as it is because of its origins and much of the code hasn't
changed for many years.  So what you see is not what we would write if
we were to do it now.

In fact I think it is quite remarkable that we have got it working
pretty well on Windows x64 with 64-bit integer support.  We do still
sometimes see 32/64 bit issues but they are, gladly, increasingly rare.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: [ANN] Job opening in Kaiserslautern for 6 months

[Brian Gladman]

On 12/05/2016 19:10, 'Bill Hart' via mpir-devel wrote:
> 
> On 12 May 2016 at 20:07, Jean-Pierre Flori  > wrote:
> 
> Anyway, is there really any reason to superoptimise on Windows
> itself, why not do it on Linux and use it everywhere, does the noise
> produced by the OS really matter?
> 
> That's the best solution in my opinion.

Yes but it does mean putting in the prologue epilog sequences since (as
you say below0 you won't get the optimisation for small length operands.

The way that GMP do it is (at least when I last looked) is to simply use
their own prologues to swap the different register conventions while
completley ignoring the need for the x64 prolgues and epilogues.  That
will work when things go well but I want a system that works in the
worst case on Windows, not only one that works when things aare going in
our favour.

> Ok, the function call ABI is different (Win64 vs system v), so when
> you enter your function some stuff will be on the stack rather than
> in registers, but apart from that, will anything really change?
> Why not go the GMP way which just add some prologue/epilogue to its
> system v function abi assembly implems to deals with the different
> windows 64 ABI?
> 
> 
> No this won't work. You must superoptimise with the correct ABI or the
> result will be useless for small operands. Alex's idea of writing code
> to deliberately put the data in the registers required for the Windows
> ABI, then optimise that on Linux is the best, I think.
> 
> We basically already did it the way you suggested and it doesn't lead to
> the right speedup on Windows.

That is what Jason and I found too.  The prologue and epilogue code
don't matter much for large operands but the statistics seem to suggest
that short operand performance is critical aand this requires Windows
ABI specific optimisation.

> And there is the stack rewinding or structured exception handling
> stuff that also needs to be dealt with but can't it be done around
> the core assembly implems as for dealing with the different function
> call ABI?

Sorry but I have just answered that before you asked it :-)

   all the best,

  Brian

PS to Antony, its nice to see your Windows experience showing up on the
list!

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: [ANN] Job opening in Kaiserslautern for 6 months

[Brian Gladman]

On 12/05/2016 17:03, 'Bill Hart' via mpir-devel wrote:
> For anyone that would like to help with porting to Windows, here are the
> notes so far:
> 
> * The asm jit we use mentions MSVC support on its website, though it
> only explicitly mentions MSVC 2003. I don't see any VS solution files,
> so I don't know how the build is managed (they use CMake).

Hi Bill,

If it is this one, it seems to have support via Cmake for VS 2015.

  https://github.com/kobalicek/asmjit

> * Bear in mind that supporting anything other than the assembly formats
> currently supported is a massive task. Alex has spent months adapting it
> to work with our assembly code, though it does read quite a bit of our
> yasm code and a lot of gas format assembly. It currently outputs gas
> format. It can output Intel syntax (we are not sure what variety), but
> that part contains some bugs (incorrect output).
> 
> * The superoptimiser itself is written in C++11, and Alex says he
> doesn't use many longs in his code.
> 
> * Currently there is code that is Linux specific for fixing the CPU
> affinity. That would need porting.

I do this regularly so it should not be an issue.

> * Until today we were having a lot of problems on Intel CPUs on any OS.
> AMD is more stable though still not perfect.
> 
> * We have not tested again on a fully loaded system. We are trying that
> now, after the most recent changes. We previously had problems on loaded
> systems. 
> 
> * As mentioned, we do not believe timings will be consistent enough on
> Windows to be able to superoptimise, but people are welcome to try and
> figure out how to make it work there. At the least it is going to
> require someone with a lot of Windows experience to solve that, if it is
> actually possible.

Well, I am finding things better than they used to be so it may be worth
trying it.

> * The total amount of code asm jit + optimiser is about 32,000 lines of
> code, but currently the code is in a state of flux, day-to-day

> * Alex does not have experience developing on Windows and does not have
> access to a Windows machine and he is on contract to the OpenDreamKit
> project, so he is not available to assist in the development of a
> Windows port, other than to answer occasional questions by email.
> 
> * Alex is currently happy to give people access to the repository on
> request (if you have a GitHub account), but please understand that the
> project is not in a stable state just yet.

I'll reflect on whether I have time to do this and get back to you guys.

But I'm inclined to give it a shot.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: [ANN] Job opening in Kaiserslautern for 6 months

[Brian Gladman]

On 12/05/2016 14:14, 'Bill Hart' via mpir-devel wrote:
> 
> On 12 May 2016 at 14:54, Brian Gladman  I ask because I am suspicious that unless i can run it myself, MPIR on
> Windows x64 will simply not get the attention it needs in maintaining a
> good level of performance.
> 
> That's possible of course.
> 
> We will make the code available publicly, and you are welcome to try and
> port it if you want.

That seems more than a little lukewarm to me and says, in effect, we
don't much care whether you do this or not.

All the more so since past experience suggests if I don't do it nobody
else will.

> But my three year Dell support contract ends in August so I will be
> spending money on my next wokstation (yes, I have to buy my own
> machines!) and it would help to know that MPIR on Windows x64 has a
> future as this could influence what I do.

Am I reading too much into your reluctance to comment on whether 'MPIR
on Windows x64 has a future'?

If I am the only one who wants this, it obviously doesn't!

   with my regards,

  Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: [ANN] Job opening in Kaiserslautern for 6 months

[Brian Gladman]

On 12/05/2016 12:52, 'Bill Hart' via mpir-devel wrote:
> Hi Brian,
> 
> I don't think the superoptimiser can be made to run on Windows.
> Experience dictates timings are not stable enough to run a
> superoptimiser, and we don't have the resources to port it. Alex is only
> with us another month and the person we hire to replace him will be
> working on actually using the superoptimiser, not further development of it.

Hi Bill,

That is disapointing.  But, timing issues apart, is it written with
portability in mind?

I ask because I am suspicious that unless i can run it myself, MPIR on
Windows x64 will simply not get the attention it needs in maintaining a
good level of performance.

> We've discussed alternatives though, such as optimising it for the
> Windows ABI on Linux (i.e. feed the data in through different registers
> than normal). We haven't checked, but it seems like it might be feasible.

At least we should be able to work as I did with Jason, that is taking
the gcc assembler, adding register exchanges, prologues and epilogues,
and then converting to Intel syntax for yasm.  But I really hoped that
we might do better than this.

Anyway, what is the priority for new assembler code going into the MPIR
repository?  I must admit that my development machine is getting rather
dated (ivybridge) so I won't be able to do much with the more recent
additions such as FMA and the like.  Which is partly why I was hoping to
run the superoptimiser myself as I can't see older machines getting much
priority.

But my three year Dell support contract ends in August so I will be
spending money on my next wokstation (yes, I have to buy my own
machines!) and it would help to know that MPIR on Windows x64 has a
future as this could influence what I do.

   with my regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: [ANN] Job opening in Kaiserslautern for 6 months

[Brian Gladman]

On 12/05/2016 10:51, Alex Best wrote:

Hi ALex,

> I have added the github user JPFlori to the (currently private) github
> repo. I would not recommend serious use yet as there are still some
> issues (if you find some let me know ;) ).
> The input and output are both switchable between gas (at&t) and yasm
> (intel) syntax, though intel output is currently untested (so likely
> buggy) and not selectable without editing the source a little.

Phew!, that's a relief as I have a profound dislike of AT&T syntax with
all those useless % symbols everywhere :-)

I am looking forward to seeing how it performs on Windows as Jason
Moxham's version never coped with the restrictions on coding in the
mandated Windows x64 prologues and epilogues.  I just accepted optimised
code outside these code sequences but I was aware that this was
suboptimal as my measurements were often slower than those that Jason got.

> Currently the abi is currently the System V AMD64 ABI, though this would
> not take too long to change if one wished.

Does this mean that the superoptimiser code is not going to port easily
to Windows?

regards,

  Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: MPIR adapter created for .Net

[Brian Gladman]

On 17/01/2016 19:28, Alex Dyachenko wrote:
> I added my actual source files into a new folder called mpir.net off the
> root of the repo.  I put the version-specific files (VS solution and
> project files) into a subfolder called mpir.net under each of the
> build.vcXX folders (excluding vc10), they all reference the same source
> files mentioned above.  However I also see the logic of creating my own
> build.vcXX subfolders within the main mpir.net, that may be a less
> confusing structure.  Let me know if you'd like me to arrange them that way.

I think it will be easier if you use a build.net directory within the
mpir directory. This way people will immediately see where your build
files are located.  Also, although conflicts are unlikely, it will be
easier of you manage the content of the build.net directory and I manage
the content of the build.vc and build.vc directoies.

   best regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: MPIR adapter created for .Net

[Brian Gladman]

On 15/01/2016 20:01, Alex Dyachenko wrote:

> At the time I started almost two years ago, there was a much simpler
> wrapper or two, searching now yields a couple, but they are both for
> integers only and don't use deferred execution.  At any rate, there
> isn't one that's officially part of MPIR, so I thought I'd make one.
> 
> Visual Studio does assume Windows; I haven't done any work in c# on
> Linux so that is indeed a very good question.  Since my interop is
> written in C++/CLI, it's most likely a no-go for Linux, but according to
> http://tirania.org/blog/archive/2011/Dec-19.html Mono on Linux can
> already consume C++ directly so I'm guessing it can just use the native
> MPIR C++ interface.  Mine was an effort to open MPIR to Windows .Net
> developers.
> 
> On Linux, "makeinfo mpir.texi" runs without error, but "make pdf" gets
> me a "No rule to make target 'pdf'".  However I can use "texi2dvi --pdf
> mpir.texi" to create a PDF; is that the same thing?
> 
> I'm confused about diff vs. whole project.  I was envisioning that my
> files, 95% of which are new and a handful existing MPIR files slightly
> modified, would become part of your repo just like Brian's VS builds now
> are.  Then anyone downloading an MPIR release sources from mpir.org
> would have the option, if they like, to build my adapter and consume it.
>  The other way this can work, and they can do it today, is if they clone
> my own fork, but I wonder if anyone in the world besides the readers of
> this thread knows about it.

Can I assume that the changes you want in MPIR itself add extra calls
without changing the MPIR external interface as it is now.  It would be
worth knowing a bit more about the changes you need here.

Do you envisage the addition of another directory witin the MPIR
directory at the same level as the build.vc and build.vc
directories?  That is something like mpir/build.net

The way we are currently working is that Bill maintains the master MPIR
repository, whereas I maintain the Visual Studio build components as a
part of my own repository at https://github.com/BrianGladman/mpir

When Bill is ready to make a new release he pulls from my repository as
a part of the process.  I imagine he would do the same with your
repository once your additions become a part of MPIR.

   best regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR adapter created for .Net

[Brian Gladman]

On 15/01/2016 16:44, Alex Dyachenko wrote:

> Hello MPIR team,
> 
> In my fork, I have created Visual Studio solutions (for versions 2012,
> 2013, and 2015) to build an adapter using C++/CLI that exposes MPIR for
> consumption by .Net 4.5+ languages.  The basic idea is that first you
> build the LIB version of MPIR using one of the existing VS
> solutions, for your desired processor architecture.  Then you build my
> solution that links to that LIB and produces a .Net assembly which
> exposes .Net classes for ints, rationals, and floats, and forwards the
> methods and overloaded operators on those classes to native MPIR calls.
>  Similarly to the native C++ interface, most operations are implemented
> through overloaded operators that produce expressions with
> deferred-to-assignment evaluation, such that a single operation (e.g. a
> = b + c) results in a single MPIR call (mp*_add), while more complicated
> expressions will use temporaries as necessary.  (The actual syntax would
> be a.Value = b + c; the reason for that is that .Net does not support
> overloaded assignment).  This is not just a set of pinvoke signatures,
> but a full OO interface.

This sounds like a useful addition to MPIR as .Net development is very
popular on Windows.

> This effort is now complete with a full suite of unit tests and XML
> comments on the entire public interface (which feed nicely into Visual
> Studio intellisense), tested under both Win32 and Win64, and can of
> course be linked to any processor-specific assembly-optimized build of
> MPIR.  I had to make one small refactoring to the existing MPIR code in
> the raw IO area where the existing entry point was at too high a level
> to be reused, and I split a method in two so I could use my own memory
> allocation and call into the "meat" of the raw IO.  This resulted in a
> couple of new entry points being added to mpir.h but no existing
> signatures were changed.  I could have re-implemented this method
> entirely in my code to avoid making any changes to the MPIR proper, but
> that wouldn't have been in the spirit of writing an adapter whose
> internals are all forwarded.
> 
> I would like to create a pull request to have this addition code
> reviewed and eventually merged in.  I realize this may take a while, and
> I'll be happy to answer your questions and/or tweak the implementation
> based on your input.  I'm also willing to support it in future MPIR
> releases.  Before I do the pull request, I wanted to post this as a
> heads up and to get initial feedback from you as to whether you're
> interested in general.

Your willingness to maintain and support this potential addition is very
important and counts as a big plus point for its inclusion.  It would
also be nice to add a new dewveloper to the MPIR team!

> Also I would like to write up a chapter for the manual, which will
> probably be similar in size and structure to the C++ interface chapter,
> however I'm not sure what tool chain you're using for that.  I have a
> linux VM where I'm able to edit texi sources in the doc folder and
> produce a PDF from them, but if I understand correctly these are
> dual-purpose sources that also work in some other tool that perhaps
> parses out the special texi instructions that don't seem to do anything
> for PDF output, and I wouldn't want to break that.  If you let me know
> the official way to edit and test the documentation, I can get started.

This is a great proposal which will offer a worthwhile addition to MPIR.

If this raises any issues that need attention in my existing VS
solutions, I will be happy to take a look at these.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fwd: Fw: Compilation on Windows

[Brian Gladman]

On 30/12/2015 09:29, Rafael Guglielmetti wrote:

[snip] There is the same errors in the lines:
 167, 218, 291, 335, 343, 380, 427, 434, 462, 547, 595, 631,
 699, 744,
 786, 796
>>
>> I would expect these to be treated as warnings rather than errors - have
>> you enabled the 'treat warnings as errors' compiler option in your projects?
>>
>>Brian
> 
> Nop, it is disabled. I also tried to disable all warnings but it does not 
> solve the problem.

Thanks for checking this.  All the errors are the result of this bit of
code:

  -static_cast(l)

giving:

  error C4146: unary minus operator applied to unsigned type, result
  still unsigned (main.cpp)

I am no expert on C++ so I am hoping that someone on this list might be
able to see why this fails.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fwd: Fw: Compilation on Windows

[Brian Gladman]

On 29/12/2015 12:59, 'Bill Hart' via mpir-devel wrote:
> 
> -- Forwarded message --
> 
> 
> --- On Mon, 12/28/15, Rafael Guglielmetti  > wrote:
> 
>> From: Rafael Guglielmetti  >
>> Subject: Compilation on Windows
>> To: hart...@yahoo.com 
>> Date: Monday, December 28, 2015, 10:22 AM
>> Dear MPIR team,
>> First, thank you four the project, it will be of great help
>> since using
>> gmplib on Windows is quite complicated.
>>
>> I successfully built the lib_mpir_cxx, dll_mpir_gc projects
>> on Windows
>> with the files you give (MPIR 2.7.2). My configuration is
>> the following:
>> * Visual Studio 2013 Community
>> * Windows 7 x64
>> * Solution file used: build.vc12\
>>
>> However, when I tried to add the files to another project
>> (either my
>> working project or a blank project), I get a few errors
>> during the
>> compilation with the file "mpirxx.h".
>> The error is the following:
>> Error1error C4146: unary minus
>> operator applied to unsigned
>> type, result still unsigned (main.cpp)   
>> C:\mpir\mpirxx.h121
>>
>> There is the same errors in the lines:
>> 167, 218, 291, 335, 343, 380, 427, 434, 462, 547, 595, 631,
>> 699, 744,
>> 786, 796

I would expect these to be treated as warnings rather than errors - have
you enabled the 'treat warnings as errors' compiler option in your projects?

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Build warning about missing cdata\mpn\generic\cfg.h

[Brian Gladman]

On 18/12/2015 14:55, ErichSt wrote:
> When building MPIR 2.7.2 with VS 2015, I'm getting below warning about 
> missing file cdata\mpn\generic\cfg.h
> 
> 10>  building MPIR for gc (x64) from directory mpn\generic
> 10>  creating mpir.h for x64
> 10>  The system cannot find the file cdata\mpn\generic\cfg.h.
> 
> Should I be concerned, or is this to be expected?  Thanks!

No, its harmless.  But its an output I will remove in our next version
as it should not be present.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 24/11/2015 22:26, SeVlaT wrote:
> 
> Do you mean here for four versions of Visual Studio?
> 
> Yes. But I see vc10 already have gone.

Yes, I don't think it makes sense to support more than the three most
recent Visual Studio versions.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 24/11/2015 22:26, SeVlaT wrote:
> 
> Do you mean here for four versions of Visual Studio?
> 
> Yes. But I see vc10 already have gone.
> 
> Today I generated all 27 Msvc14 projects and tried to build them
> I've got a lot of errors due to vsyasm cannot understand option "-f Win32".
> 
> I fixed vsyasm.props to make platform name lowercase (see my pull
> request). All projects now compiles.
> I cannot yet understand how this projects compiled before?
> 
> So I think I do something wrong.
> vsyasm.props is a part of VSYASM compiler and it should not contain such
> errors.

This is a bug in VSYASM that was fixed over a year ago.  You need to
update your VSYASM executable.

> Also there are some obscure things with vsyasm.
> We can see command line used for vsyasm. In property dialog, or in build
> log. Some path parameters e.g. IncludePath has two backslashes at the
> end. I cannot understand why.
> I tried to remove trailing backslash in vcxproj/vsyasm settings -
> trailing double slash disappeared.

I also have an oddity - in the Visual Studio configuration manager my
WIn32 configuration is being renamed as x86!  I have no idea why!

   regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 24/11/2015 09:38, SeVlaT wrote:
> I have all of them.
> 
> What exactly should be tested?

That is a very good quation!

With 27+ varients each combined with both  and ,
it is not practical to build and run the tests on Windows even for one
version of Visual Studio without further build automation (which I have
thought about).

> My variant:
> 1. Set usecpp=True to generate cxx project
> 2. Run mpirconfig four times and pass him all numbers 1-26

Do you mean here for four versions of Visual Studio?

> 3. Ensure that all solutions are buildable

Under normal circumstances, I only test the with the current version of
Visual Studio (2015 now).

But with all the recent changes I am going to ensure that Visual Studio
versions 2012, 2013 and 2015 are all working.

I don't however test all variants. Unless I expect a specific problem, I
only build and run the tests for the GC versions and for my current
processor (sandybridge_ivybridge).  I don't do any testing of win32
builds other than GC as I consider all these builds obsolescent.

At the moment the vc14 version is fairly complete and should be fully
working.

Yesterday, I completed the corrections needed for the vc12 version but I
haven't yet committed them.  I hope to complete this later today.

When I have finished vc12 I will move on to VC11.

I do not intend to offer support for earlier versions (Visual Studio
2010 and earlier).

  regards,

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 23/11/2015 21:36, SeVlaT wrote:
> Hi.
> 
> I have added it now but with a different name (I assume it will
> have the *.props extension anyway).
> 
> I've not found this in your repository.
> So I did it in my msvc1 branch and made a new pull request.
>  
> 
> But I am not sure how to test this as I don't normally build with
> MSBUILD.
> 
> To create some property sheet and make sure that it really used by
> project. For example, test props may contains: echo It
> works!.
> 
> I've tried external props at my job: I've compiled lib_mpir_gc with
> /MD(d) in msvc 12 and 14. It seems to work.
> 
> There are also some fixes in this PR:
> 1) An original Windows directory separator is a backslash. Msbuild is
> often tolerant to forward slashes and even to mixture of slashes, but
> not always.
> So it worth to follow the same rules in all paths in msbuild scripts.
> 
> 2) I failed to build any DLL project in msvc 10-12 due to wrong
> Link/GenerateDebugInformation value. Value "true" is supported by all
> Msvc versions

Thanks Sergey,

I've merged your fixes now.

Which Visual Studio versions have you been able to check with the latest
build files?

   regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 22/11/2015 04:20, SeVlaT wrote:
> For example, the same way as I did in my previous pull request:
> https://github.com/sevlat/mpir/commit/591918b046f251743aa3376df02bfcbd6b2220ca
> 
> I can do it again but not now. Maybe tomorrow.

Its OK, I have added it now but with a different name (I assume it will
have the *.props extension anyway).

But I am not sure how to test this as I don't normally build with MSBUILD.

  regards,

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 21/11/2015 21:30, SeVlaT wrote:
> Thank you very much, Brian!
> 
> I have observed your commits during this week.
> I see that many files (*.bat, *.c, *.h) was moved to build.vc directory
> and became common. Probably this structure will be much clear and easier
> to support.
> 
>> However I have not adopted an approach that relies on property sheets
> to the extent that you have done. Instead I use only four common
> property sheets for lib/release, lib/debug, dll/release and dll/debug.
> Good. There should be a "golden mean" for extent of using property
> sheets.  I think you feel it better then me.
> 
> Now I have not enough time so I have just glanced on you files and
> quickly tested them for MSVS 2015.
> I noticed a couple of errors and fixed them in my new pull request
> (branch "msvc1")

Thanks for the fixes.

> By the way, what are you think about external property sheet
> (MPIR_Props_External)?

Yes, that would be a good idea - how do I add this?

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Open source high precision math tools built under 64 bit Windows operating systems state of the union

[Brian Gladman]

On 19/11/2015 22:57, Dann Corbit wrote:
> The compiler I was using was 64 bit Mingw gcc, from this location:
> 
> http://tdm-gcc.tdragon.net/
> 
> I have found that it is much harder to get Visual Studio build chains to
> work all the way to the end.

I can't comment on the content of most of this thread since I don't use
non-native tools on Windows. But I am interested in what does and
doesn't work when Visual Studio is used.

Building the bottom end of the hierarchy you are creating should be
straightforward with Visual Studio (except for GMP).

The VS builds for MPIR and MPFR are mature and should just work out of
the box.  The VS build for FLINT should work but it is very new (in
comparative terms) so I would not be surprised if it has some issues.

But I have had no feedback from anyone on its operation so if it does
have problems, nobody has bothered to report them to me.

But Arb is a different matter, I'm afraid as I have not even tried to
develop a Visual Studio build for it.

regards,

  Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 06/11/2015 21:44, SeVlaT wrote:
> 
> Hi.
> 
>> I am not sure I understand your concern. Whether an MPIR build uses
>> the normal or the debug libraries is set by mpir_config.py.
> 
> I'll try to explain about UseDebugLibrary.
> 
[snip]

Hi Sergey,

> What happen if vcxproj has no ? MSProps will not know
> that some ProjectConfigurations are intended for debugging. It will
> consider all ProjectConfigurations as release - turn on optimization,
> skip debug info, etc.
> 
> So I think it worth to add  to both new-style and
> old-style projects.

This becomes an issue if people don't explicitly specify the libraries
that they are going to use. But in our case we explicitly set up the
correct libraries for Release and Debug so we don't make any use of the
MSProps defaults, which means that we don't need .
Nevertheless, I don't think it would do any harm to add it.

>> I had rather hoped that the two solutions could be merged ...
> As for solution merging, I suppose I don't understand it.
> Old-style solution file is just a list of old-stile projects and
> new-style solution file is a list of new-stile projects. Old-style and
> new-style solution files are quite the same. How we can merge them?
> Do you intend to put both old-stile and new-stile projects into the same
> solution? Yes, it's possible if projects have different names. For
> example, new-style projects will have a '_p' suffix, as it was
> previously. But is that a good idea? I think that a large solution with
> duplicate projects will confuse users.
> 
>> But I am much less convinced about the merits of moving all properties
>> into property sheets.
> With old approach each project file contains about 20 settings per each
> ProjectConfiguration.

Yes, but these properties are not managed in the project files, which
are all autogenerated from a single mpir_config.py file for each MSVC
version.  So to change a property all that is necessary is to modify the
relevant mpir_config.py file.  Here I do think your adoption of a common
mppir_config.py across different MSVC versions is a good one which I
intend to look at.

There are also good reasons for adopting a common overall props file for
those properties that bring significant simplifications of the
vcxproject files. Here your use of $(IntDir)\dum\my\%(RelativeDir) is a
brilliant approach and one that I intend to adopt. This has a big effect
since it impacts on every source file line whereas other properties are
not subject to such a big text expansion factor in the vcxproj files.

Also the rationalisation of mpir_config.py into orthogonal components
has been on my todo list for some time.

> With new approach we have about  20 property sheets, with 1-2-3 settings
> in each. Also props files has clear names (it's  clear, what settings
> are in common.dll.debug.props) and all located in one place -
> props_common directory. And projects contain no settings - only primary
> properties.
> 
> I suppose two building approaches may exist concurrently. User
> accustomed to old approach could use old solutions as the did previously.

I am doubtful about adding two approaches for the Windows build as a
part of the standard MPIR distribution.  Most people just want to build
MPIR 'out of the box' so adding two approaches that do the same thing
from their perspective doesn't add much real value. It would be better
to offer one or the other.

And in order to switch to your approach either I would have to adopt it
or you would have to make a long term commitment to become the Windows
build maintainer for MPIR.

The first of these options is certainly possible but it will be quite
some time before I will get to a point where I am ready to contemplate
such a switch.

However I would not personally be adverse to passing the maintainer role
to you if you are in a position to commit to undertake it in the long
term (subject, of course to this being acceptable to the MPIR team).

And, of course, for now we could simply advertise the fact that you are
offering an alternative MSVC build in your GIT repository.

   best regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 03/11/2015 19:14, SeVlaT wrote:
> Thank you for explanation.
> I made two new mpir_config.py files, they generate old-styled and new-styled 
> projects. 
> You may play with them, they are in build.vc directory in my repository, 
> branch msvc_config: https://github.com/sevlat/mpir/tree/msvc_config
> There is also a readme.txt in this directory.

I tried your alternative MSVC build system today.

There is an issue that needs fixing but, apart from this, it works for me.

The issue is that your build directories need the file 'cfg.h'

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 03/11/2015 19:14, SeVlaT wrote:
> Thank you for explanation.
> I made two new mpir_config.py files, they generate old-styled and new-styled 
> projects. 
> You may play with them, they are in build.vc directory in my repository, 
> branch msvc_config: https://github.com/sevlat/mpir/tree/msvc_config
> There is also a readme.txt in this directory.

Thanks for the hard work.  I am a bit busy right now but I hope to look
at what you have done as soon as possible.

Are you willing to make a commitment to support this alternative build
approach on an ongoing basis if it was to be added to the MPIR standard
distribution?

When your approach is complete, what would need to be added to MPIR (you
seem to have a lot of temporary directories around at the moment)?

  best regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 03/11/2015 10:21, SeVlaT wrote:
> Can anybody explain mpir_config.py command line parameters?
> 
> It expect at most one parameter - a number. If it doesn't have a second bit, 
> the program will exit after doint allpreliminary job, but before asking user 
> about desireble processor architecture. If it have both bits 1 and 2 the 
> program works the same way then without any command line parameter.

All Python programs have at least one parameter because the program's
name is put in argv[0] automaticaally when it is launched.  So a program
that has no command line parameters will have len(argv) == 1.

Normally mpir_config.py is called with no command line parameters and it
then asks the user for their desired architectures.

When it is called with a parameter it does the preliminary work to
create files such as config.h, longlong.h, ... but it does not build the
MSVC project files.

This is because mpir_config.py was used in two build systems - the
Visual Studio build system and the MSDOS based command line build - and
the latter build needs the preliminary work but not the MSVC project
part of mpir_config.py. But the MSDOS based build is not being
maintained at the moment so for use with MSVC, which I believe is your
interest, mpir_config.py is called with no command line parameters.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 30/10/2015 14:33, SeVlaT wrote:
> Thank you.
> 
> And yet another error: line 532
> 
> yasm_options(plat, ...)
> 
> plat here is a tuple, while yasm_options required an element of this tuple. 
> As a result, mpirconfig always generate mpn/x86_64w for include path for 
> yasm, even for win32 platforms.
> 
> Probably should be:
> 
> yasm_options(pl, ...)
> 

Yes - its great to have a new bug hunter on board - keep up the good work!

By the way there are several problems and bugs in the part of the code
that writes the *.sln file.  You may need to update this paqrt of your
code later because the bugs need to be removed as they might prevent
Visual Studio loading the solution file in some circumstances.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 28/10/2015 22:03, SeVlaT wrote:
> 
> > For information here are the project type ID that I know about so
> far:
> >
> > Solution Folder:2150E333-8FDC-42A3-9474-1A3956D46DE8
> > Visual C/C++ Project:   8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942
> > Visual Basic Project:   F184B08F-C81C-45F6-A57F-5ABD9991F28F
> > Python Project: 88A0-9F3D-457C-B088-3A5042F75D52
> > Fortran Project:6989167D-11E4-40FE-8C1A-2192A86A7E90
> 
> It looks like Yvan Rodrigues has done some of the work on project type
> GUID's here:
> 
> 
> http://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
> 
> 
> 
> 
>  Yes, {8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}, that used in vc10-vc12
> directories, is a "Visual C/C++ Project" guid,
> but vc14 {59348fde-2f50-426c-9f74-184aa069c067} is unknown guid. Is it
> an error?

Yes.

> 
> Now I am researching mpir_config.py scripts and developing property
> sheet structure.
> I made a copy of build.vc12 directory - build.vc12.p, but with my
> solution, projects, and property sheets, and do my work in this new
> directory (and also in build.vc)
> You may see it in my repository, branch msvc_props:
> https://github.com/sevlat/mpir/tree/msvc_props
> 
> When I'll finished a property sheet structure, I'll begin to adapt
> mpir_config.py. I suppose it'll became shorter and simplie, because an
> considerable part of mpir_config-s logic is now performed by property
> sheets.
> 
> The next question about mpir_config.py.
> What is "app_type"? Does it really used, or will be used in future?
> If does, the following code probably contain an error (line 470).
> 
>   if proj_type == app_type:
> s1 = 'DEBUG;WIN32;_CONSOLE'
> s2 = ''
>   if proj_type == dll_type:
> s1 = 'DEBUG;WIN32;HAVE_CONFIG_H;MSC_BUILD_DLL;'
> s2 = 'DLL'
>   elif proj_type == lib_type:
> s1 = 'DEBUG;WIN32;_LIB;HAVE_CONFIG_H;'
> s2 = ''
>   else:
> pass
>   if plat == 'x64':
> s1 = s1 + '_WIN64;'
> 
>  s1 for dll and lib ends with semicolon, but s1 for app doesn't. We'll
> possibly get a wrong result in the last line of this flagment.

Yes, all the s1 strings should end with a semicolon.  The three
different builds are *.exe (app_type), *.dll (dll_type) and *.lib
(lib_type).

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 27/10/2015 21:49, Brian Gladman wrote:
> On 27/10/2015 19:36, SeVlaT wrote:
> 
> [snip]
> 
>> And yet another question.
>> Why build.vc14\mpir_config.py use some new vcxproject guid -
>> {59348fde-2f50-426c-9f74-184aa069c067} (line 638) while all previous
>> mpir_config.py-s used well-known prpject guid
>> {8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}?
> 
> For the moment, you don't need to take much notice of the project type
> GUID's in the *.sln files as I am in the process of discovering what
> these values should be.
> 
> I have several changes that I want to make in the reading and writing
> solution files and I intend to put the GUID's right when I make these
> other changes.
> 
> For information here are the project type ID that I know about so far:
> 
> Solution Folder:2150E333-8FDC-42A3-9474-1A3956D46DE8
> Visual C/C++ Project:   8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942
> Visual Basic Project:   F184B08F-C81C-45F6-A57F-5ABD9991F28F
> Python Project: 88A0-9F3D-457C-B088-3A5042F75D52
> Fortran Project:6989167D-11E4-40FE-8C1A-2192A86A7E90

It looks like Yvan Rodrigues has done some of the work on project type
GUID's here:

http://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 27/10/2015 19:36, SeVlaT wrote:

[snip]

> And yet another question.
> Why build.vc14\mpir_config.py use some new vcxproject guid -
> {59348fde-2f50-426c-9f74-184aa069c067} (line 638) while all previous
> mpir_config.py-s used well-known prpject guid
> {8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}?

For the moment, you don't need to take much notice of the project type
GUID's in the *.sln files as I am in the process of discovering what
these values should be.

I have several changes that I want to make in the reading and writing
solution files and I intend to put the GUID's right when I make these
other changes.

For information here are the project type ID that I know about so far:

Solution Folder:2150E333-8FDC-42A3-9474-1A3956D46DE8
Visual C/C++ Project:   8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942
Visual Basic Project:   F184B08F-C81C-45F6-A57F-5ABD9991F28F
Python Project: 88A0-9F3D-457C-B088-3A5042F75D52
Fortran Project:6989167D-11E4-40FE-8C1A-2192A86A7E90

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 27/10/2015 07:09, SeVlaT wrote:
> So,
> 
> build.vc10\mpir_config.py -- search in build.vc10
> build.vc11\mpir_config.py -- search in build.vc11
> build.vc12\mpir_config.py -- search in build.vc12
> build.vc14\mpir_config.py -- search in build.vc12?

No, the last one should be:

build.vc14\mpir_config.py -- search in build.vc14?

I think you may be working from the wrong repository since if you look
at the vc14 version of mpir_config.py in my GITHUB repository at:

https://github.com/BrianGladman/mpir/blob/master/build.vc14/mpir_config.py

the relevant lines are:

# paths that might include source files(*.c, *.h, *.asm)
c_directories = ('', 'build.vc14', 'fft', 'mpf', 'mpq', 'mpz',
 'printf', 'scanf')

I think Bill Hart's repository is the same but I will have to check this.

In any event, if you are playing with anything in the vc12 or vc14
directories, it is my repository that is the most up to date as Bill
tracks my changes for MSVC stuff. So you should really be tracking my
repository for the MSVC stuff if you want the current state of the MSVC
build.

I hope this helps but if not please get back to me.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 26/10/2015 22:58, SeVlaT wrote:
> Thank you for a detailed answer.
> 
> In general, I totally agree with you.
> 
> it would hence
> be desirable to modify mpir_config.py to generate your simpler
> *.vcxproj
> files and also generate any property sheets that contain details that
> depend on processor architectures.  This is certainly possible but
> it is
> not a trivial exercise
> 
>  
> 
> You might however want to tackle this yourself as it would make it easy
> to maintain your alternative build approach and also provide an easy
> way
> of switching between and comparing the two approaches.
> 
> I'll try to do that. I looked into mpir_config.py and I suppose it is
> not very difficult or time-taking to modify mpir_config.py.
>  
> Could you explain, why all four mpir_config.py looks for source files in
> directory 'build.vc12' (see line 45)
>
> Is it an error? May be there should be a version corresponding
> directory: 'build.vc10', 'build.vc11' etc. ?

Yes, this is an error in the mpir_config.py files in the vc10 and vc11
directories but those in the vc12 and vc14 directories are correct (the
vc10 and vc11 directories are no longer maintained)

> It seems to me, this item may be totally deleted from the list. Because
> build.vcNN directories contains no source files - all existing *.c and
> *.h files are listed in exclude_file_list (see line 50), so
> mpir_config.py takes nothing from build.vcNN directory.

I scan the vc for source files because it is necessary to have a
location for source code files that are specific to MSVC (and the MSVC
version) but which are not a part of the MPIR source code itself.

Although it is true that we don't need to pick up any files needed by
MPIR from these directories at the moment, we have needed such files in
previous MPIR releases and we may need them in future.  Also some
developer applications (in the tune directory) do need source code files
from the vc directory and may in future be generated by mpir_config.py.

So for these reasons I am keeping the principle of scanning _all_
directories where source code files _might_ be located.  And then simply
listing file exclusions for MPIR.  If I add another application build to
mpir_config.py I will simply add a different file exclusion list.

You could drop this approach if you wish, but please bear in mind that
you might need to put it back (or do someting equivalent) in future as
there could be files added to vc that are needed.

I should also mention that mpir_config.py needs major improvements by
reorgnising the various operations into separate modules. I would like
to separate out the analyser and the project file generation so that I
can use the analyser with an MSVC project file builder (as now) or with
builders for DOS and MSBUILD builds.  I haven't had time to do this yet
but it is still on my 'to do' list.

I hope this answers your questions, but if not please feel free to ask
for further clarification as I am pretty sure you will find further
issues and bugs. Having someone else going through code is always a good
thing as the code will almost certainly improve as a result!

   best regards,

 Brian




-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Simplifying MSVC projects: using PropertySheets

[Brian Gladman]

On 23/10/2015 23:33, SeVlaT wrote:
> A month ago I tried to compile MPIR. I noticed that *.vcxproj files are very 
> heavy in size and contains a lot of redundant parameters. So I decided to 
> simplify project files and move all properties to separate *.props files.
> 
> That is my Pull Request for it:
> https://github.com/wbhart/mpir/pull/163

Thank you for your interest in the MSVC build system for MPIR.  Your
approach is certainly interesting and might offer advantages when
compared with the current build approach.  Is it your intention to offer
an alternative or an additional MSVC build system?

The problem with offering two build systems is that we would have to
maintain both of them and this would only make sense if: (a) they
offerred substantially different features, and (b) we are confident that
we have the necessary resources to maintain both of them.

If your approach is offered as an alternative (i.e. it is intended as a
replacement of the current build system) we then have to understand what
advantages it will offer and here, from what you say, your approach
would make the *.vcxproj shorter and easier to understand.

But since the majority of the users of the MSVC build system simply load
and build them without ever needing to understand them, the benefits
your approach could offer won't impact on most users. It is really only
core MPIR developers on MSVC - those who need to understand and maintain
the *.vcxproj files - that will benefit. And this means basically me!

In terms of maintaining the *.vcxproj files, it is important to
understand that the current build system doesn't maintain these files
since they are automatically generated.  When the file mpir_config.py is
run it offers the end user a choice of processor architectures and for
each selection made it then writes out the appropriate config.h,
longlong.h, vcxproj and vcxproj.filter files for the requested
architecture(s).  So, although it might seem that there are many complex
MSVC project files that need to be maintained, in practice only one file
- mpir_config.py - is involved in maintenance.

In order to adopt your approach based on property sheets, it would hence
be desirable to modify mpir_config.py to generate your simpler *.vcxproj
files and also generate any property sheets that contain details that
depend on processor architectures.  This is certainly possible but it is
not a trivial exercise and not one I would want to embark on unless it
was clear that this would provide significant advantages over the
current approach in terms of build maintenance and support.

You might however want to tackle this yourself as it would make it easy
to maintain your alternative build approach and also provide an easy way
of switching between and comparing the two approaches.

  with my regards,

Brian Gladman

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fwd: [mpir] Yasm settings fix (#162)

[Brian Gladman]

On 22/10/2015 15:29, 'Bill Hart' via mpir-devel wrote:
> 
> -- Forwarded message --
> From: *sevlat* mailto:notificati...@github.com>>
> Date: 22 October 2015 at 16:24
> Subject: [mpir] Yasm settings fix (#162)
> To: wbhart/mpir mailto:m...@noreply.github.com>>
> 
> 
> It seems that item YASM/ObjectFileName makes no sence in MSVC projects.
> It is not mentioned in either vsyasm.xml, vsyasm.props, vsyasm.target,
> so Studio does not know what to do with this item.
> I suppose that YASM/ObjectFileName was used in the past, but now it
> obsolete and replaced by YASM/ObjectFile item.
> 
> I removed YASM/ObjectFileName from all projects and mpir-config.py
> Thank you.

Yes, this is a left over from long ago.  Its completely benign but I
will remove it before we issue a new release.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fwd: [mpir] mpz.fac_ui : ERROR with x64 Release configuration on Visual Studio 2015 (#159)

[Brian Gladman]

On 08/09/2015 21:02, Brian Gladman wrote:
> On 08/09/2015 18:30, 'Bill Hart' via mpir-devel wrote:
>>
>> -- Forwarded message --
>> From: *Tomi* mailto:notificati...@github.com>>
>> Date: 5 September 2015 at 18:24
>> Subject: [mpir] mpz.fac_ui : ERROR with x64 Release configuration on
>> Visual Studio 2015 (#159)
>> To: wbhart/mpir mailto:m...@noreply.github.com>>
>>
>> excerpts from run-tests.py script output:
>>
>> Testing MPIR Static Library (lib_mpir_k8_k10_k102) in Configuration
>> ...
>> mpz.divis_2exp : success
>> mpz.export : success
>> mpz.fac_ui : ERROR ( 3221225477 )
>> mpz.fdiv : success
>> ...
>> subc : success
>> 201 tests:
>> 200 ran correctly
>> 1 failed
>> .. completed - press ENTER
>>
>> (builded with Microsoft Visual C++ 2015 (Enterprise Edition) on Windows
>> 7 - 64 bit)
>>
> 
> I can see this error but it won't be easy to debug as the failure
> occcurs in the karatsuba multiplication code.  I suspect that something
> is wrong with the thresholds set in gmp-mparam.h for this architecture.

I have found the problem - there is a bug in the karasub.asm assembler
used on Windows for the K10/K102 architectures.

Looking at the K8/K10/K102 code in x86_64 (i.e. the GCC/Linux code) it
makes sense to fix the bug by simply using K8 assembler code for the
K10/K102 architectures on Windows.  This fixes the bug.

I have added this change to my GITHUB MPIR repository.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fwd: [mpir] mpz.fac_ui : ERROR with x64 Release configuration on Visual Studio 2015 (#159)

[Brian Gladman]

On 08/09/2015 18:30, 'Bill Hart' via mpir-devel wrote:
> 
> -- Forwarded message --
> From: *Tomi* mailto:notificati...@github.com>>
> Date: 5 September 2015 at 18:24
> Subject: [mpir] mpz.fac_ui : ERROR with x64 Release configuration on
> Visual Studio 2015 (#159)
> To: wbhart/mpir mailto:m...@noreply.github.com>>
> 
> excerpts from run-tests.py script output:
> 
> Testing MPIR Static Library (lib_mpir_k8_k10_k102) in Configuration
> ...
> mpz.divis_2exp : success
> mpz.export : success
> mpz.fac_ui : ERROR ( 3221225477 )
> mpz.fdiv : success
> ...
> subc : success
> 201 tests:
> 200 ran correctly
> 1 failed
> .. completed - press ENTER
> 
> (builded with Microsoft Visual C++ 2015 (Enterprise Edition) on Windows
> 7 - 64 bit)
> 

I can see this error but it won't be easy to debug as the failure
occcurs in the karatsuba multiplication code.  I suspect that something
is wrong with the thresholds set in gmp-mparam.h for this architecture.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] [ANN] Flint 2.5 released

[Brian Gladman]

On 10/08/2015 22:49, Dann Corbit wrote:
> I can’t run the tests because it is not obvious to me how to set the
> include file paths for python.  I get errors like this when I run
> build_tests.py:

Hi Dann,

The layout on which the MSVC build is based is explained in the
documentation. It is:

 mpfr
   dll dll outputs
   lib static lib outputs
   build.vc14  MSVC build files
 mpir
   dll
   lib
   build.vc14
pthreads
   dll
   lib
   build.vc14
pthreads
  dll
  lib
  build.vc14

This is the standard layout I use on all the open source packages I
provide since it allows them to work together.  The need for pthreads is
listed in the documentation - it is available here in the form needed:

  https://github.com/BrianGladman/pthreads

I can supply the mpfr build files as well if you need them (I would put
them on my GITHUB site but the mpfr folk run subversion and I am very
uncertain about using a repository that imports from subversion and
exports to GIT :-(

I am not sure why you need a second definition of _alloca.  I should
also mention that I have only set up the tests to work with a staic
library build.

   best regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] [ANN] Flint 2.5 released

[Brian Gladman]

On 08/08/2015 05:22, Dann Corbit wrote:
> Won’t build on Windows.  There is a problem with the Conway polynomial
> stuff.  There is no file CPimport.h as required by the file
> \flint-2.5.0\qadic\ctx_init_conway.c and no script that I saw generates
> that file on Windows.

Sadly that's an error on my part.  This error occurs because the step
that adds the FLINT tests to the Windows build also adds this file.  So
the error only occurs when FLINT2 is built without installing the tests

I can fix it either by changing the documentation to insist that the
tests are installed before FLINT2 is built or by adding a prebuild step
to the FLINT2 build.

This will be an easy fix either way, one which I will do quickly.

In the meantime just run flint_config.py before building FLINT2

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Errors building 2.7.0 with visual studio 2015

[Brian Gladman]

On 22/07/2015 14:26, Russell Wallace wrote:
> On Wed, Jul 22, 2015 at 1:42 PM, Brian Gladman  <mailto:b...@gladman.plus.com>> wrote:
> 
> For x64 I would expect the core2 architecture to be pretty safe and
> reasonably fast on most current machines.
>  
> If core2 is what's recommended, if it will work on every reasonably
> up-to-date machine, that's fine. 

There is no easy answer to this.  Intel's core2 processor family was
introduced in July 2006 but x86_64 architecure processors from AMD, for
example the K8 and Opteron, were introduced in April 2003 while Intel
introduced its first x86_64 processor (Pentium 4, Presscott) in February
2004.

So using the core2 version will satisfy your customers with machines
that are less than around, say, eight years old. But if your potential
user base is large you caan pretty well guarantee that some will be
using processors that predate the Core 2.

If you want to ensure that everone gets a working solution, the only
option open to you is to use the unoptimised x64 gc (generic C) version.
 But my guess is that the Core2 will work for the vast majority of
x64_86 based PCs currently in use - but not all of them!

For distributing the batch file, can
> you take out the architecture parameter and have it always use core2?

You could certainly modify it that way as a part of your distribution
but I would not want to include it in MPIR in this form. But you could
easily use your own batch file to invoke msbuild.bat for the Core2
anyway so this should not be a problem.

> I tried it just now with that parameter in the meantime and it looks good.

That is good news - thank you for trying it out.

   best regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Errors building 2.7.0 with visual studio 2015

[Brian Gladman]

On 22/07/2015 13:09, Russell Wallace wrote:

> That does look useful! For the architecture parameter, the two common
> scenarios are:
> 
> 1. I'm going to link to a program which I'm then going to ship as a
> binary. I need something that will work correctly on every x64 CPU, and
> should preferably be optimised according to the distribution of machines
> that exists today or is projected to exist over the next few years.

For x64 I would expect the core2 architecture to be pretty safe and
reasonably fast on most current machines.

> 2. I'm compiling stuff purely to run on my own machine. I don't know
> exactly what variant of CPU it has, but would by all means like the code
> to be optimised for my CPU, whatever that happens to be.

If you install and run CPUID, available here:

http://www.cpuid.com/softwares/cpu-z.html

it will tell you what processor your PC has.

> What should be specified for the architecture parameter in each case?

The available architectures are those listed when mpir_config.py is run:

 1. gc
 2. p3   (win32)
 3. p3\p3mmx (win32)
 4. p4   (win32)
 5. p4\mmx   (win32)
 6. p4\sse2  (win32)
 7. p6   (win32)
 8. p6\mmx   (win32)
 9. p6\p3mmx (win32)
10. pentium4 (win32)
11. pentium4\mmx (win32)
12. pentium4\sse2(win32)
13. atom   (x64)
14. bobcat (x64)
15. bulldozer  (x64)
16. bulldozer\piledriver   (x64)
17. core2  (x64)
18. core2\penryn   (x64)
19. haswell(x64)
20. k8 (x64)
21. k8\k10 (x64)
22. k8\k10\k102(x64)
23. nehalem(x64)
24. nehalem\westmere   (x64)
25. netburst   (x64)
26. sandybridge(x64)
27. sandybridge\ivybridge  (x64)

Please note that msbuild.bat can only be used for those architecures
that have already been installed into the Visual Studio build. That is
those available by default and those added by running mpir_config.py (I
have updated mpir_config.py in my GIT repository so I hope the bug you
found when you ran it is not present in this version).

In msbuild.bat the architecure parameter is one of the names in the
above list with any '\' replaced by an underscore - hence the build
'sandybridge\ivybridge' above becomes 'sandybridge_ivybridge'.

I would appreciate feedback on whether msbild.bat works for you. If you
are able to try it please also update both postbuild.bat and
mpir_config.py from my GIT repository before you do this as the revised
versions are needed by msbuild.bat.  If you need help in getting these
files just email me.

  best regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Errors building 2.7.0 with visual studio 2015

[Brian Gladman]

On 21/07/2015 14:13, Russell Wallace wrote:
> It does exist, and the build now works with no errors.

I have added a commandline build for Visual Studio 2015 to my MPIR
GITHUB repository at:

https://github.com/BrianGladman/mpir

The file is msbuild.bat in the build.vc14 directory (it uses MSBUILD to
do the hard work).

This is used by opening a command prompt in the build.vc14 directory and
then entering the command:

> msbuild

where  is the version to be built and the  terms are
alternatives that set the library type (static library or dll), the
platform (Win32 or x64) and the configuration (Release or Debug).

For example:

> msbuild core2 lib x64 release

will build the core2 static library version of MPIR for x64 in release
mode, and:

> msbuild sandybridge_ivybridge dll x64 debug

will build the sandybridge_ivybridge DLL version of MPIR for x64 in
debug mode.

Hopefully this will provide a substitute for the removed command-line
build.  I have tried it successfully on several builds but it is likely
to contain bugs.  Note also that if you wish to try it, you will need to
update your postbuild.bat file (in build.vc14) to that in my GITHUB MPIR
repository.

I would appreciate feedback on this as it will be very easy to add to
MPIR if it is useful.  This is because there is almost no maintenance
cost as all the hard work is done by the existing Visual Studio builds.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Errors building 2.7.0 with visual studio 2015

[Brian Gladman]

On 21/07/2015 14:13, Russell Wallace wrote:
> It does exist, and the build now works with no errors.

Thanks Russell,

This is, I'm afraid, a bug in the Visual Studio build for Haswell - this
cfg.h file should have been in my repository when MPIR 2.7.0 was
released but sadly I had not uploaded it so it got omitted.

Thank you for discovering the issue.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Errors building 2.7.0 with visual studio 2015

[Brian Gladman]

On 21/07/2015 13:46, Russell Wallace wrote:
> C:\mpir-2.7.0\build.vc14>mpir_config.py
>  1. gc
>  2. p3   (win32)
>  3. p3\p3mmx (win32)
>  4. p4   (win32)
>  5. p4\mmx   (win32)
>  6. p4\sse2  (win32)
>  7. p6   (win32)
>  8. p6\mmx   (win32)
>  9. p6\p3mmx (win32)
> 10. pentium4 (win32)
> 11. pentium4\mmx (win32)
> 12. pentium4\sse2(win32)
> 13. atom   (x64)
> 14. bobcat (x64)
> 15. bulldozer  (x64)
> 16. bulldozer\piledriver   (x64)
> 17. core2  (x64)
> 18. core2\penryn   (x64)
> 19. haswell(x64)
> 20. k8 (x64)
> 21. k8\k10 (x64)
> 22. k8\k10\k102(x64)
> 23. nehalem(x64)
> 24. nehalem\westmere   (x64)
> 25. netburst   (x64)
> 26. sandybridge(x64)
> 27. sandybridge\ivybridge  (x64)
> Space separated list of builds (1..27, 0 to exit)? 19
> haswell ('x64',)
> Traceback (most recent call last):
>   File "C:\mpir-2.7.0\build.vc14\mpir_config.py", line 954, in 
> c_src_list + cc_src_list + mpn_f[1], af_list)
>   File "C:\mpir-2.7.0\build.vc14\mpir_config.py", line 343, in gen_filter
> makedirs(split(fn)[0])
>   File "C:\Python26\lib\os.py", line 157, in makedirs
> mkdir(name, mode)
> WindowsError: [Error 183] Cannot create a file when that file already
> exists: '..\\build.vc14\\dll_mpir_haswell'

Hi Russell,

That is odd - I suspect that this is a Python 2/3 issue.  Can you check
in your mpir source directory if the file

mpir\build.vc14\cdata\mpn\x86_64w\haswell\cfg.h

exists. If it does, try the build again. If not I'll send you a copy of
it as a temporary fix.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Errors building 2.7.0 with visual studio 2015

[Brian Gladman]

On 21/07/2015 11:48, Russell Wallace wrote:
> On building 2.7.0 with visual studio 2015:
> 
> prebuild.bat
> msbuild
> 
> I get the following errors:
> 
> Build FAILED.
> 
> "C:\mpir-2.7.0\build.vc14\mpir.sln" (default target) (1) ->
> "C:\mpir-2.7.0\build.vc14\lib_mpir_haswell\lib_mpir_haswell.vcxproj"
> (default target) (9) ->
> (Lib target) ->
>   addmul_2.obj : warning LNK4006: __gmpn_addmul_2 already defined in
> redc_2.obj; second definition ignored
> [C:\mpir-2.7.0\build.vc14\lib_mpir_haswell\lib_mpir_haswell.vcxproj]
>   addmul_2.obj : warning LNK4221: This object file does not define any
> previously undefined public symbols, so it will not be used by any link
> operation that consumes this library [C:\mpir-2.7.0\buil
> d.vc14\lib_mpir_haswell\lib_mpir_haswell.vcxproj]
> 
> 
> "C:\mpir-2.7.0\build.vc14\mpir.sln" (default target) (1) ->
> "C:\mpir-2.7.0\build.vc14\dll_mpir_haswell\dll_mpir_haswell.vcxproj"
> (default target) (14) ->
> (Link target) ->
>   redc_2.obj : error LNK2005: __gmpn_addmul_2 already defined in
> addmul_2.obj
> [C:\mpir-2.7.0\build.vc14\dll_mpir_haswell\dll_mpir_haswell.vcxproj]
>   C:\mpir-2.7.0\build.vc14\x64\Debug\mpir.dll : fatal error LNK1169: one
> or more multiply defined symbols found
> [C:\mpir-2.7.0\build.vc14\dll_mpir_haswell\dll_mpir_haswell.vcxproj]
> 
> 2 Warning(s)
> 2 Error(s)
> 
> Any idea what's causing this?
> 
Hi Russell,

It looks like haswell config data is missing.  To check this can you run
the Python script mpir_config.py and select 19 from the list of
configurations.  If you can do this, please try the build again.

If you cannot run the Python script I will send you a modified vcx
project file for haswell to try.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Repeatable procedure for building on Windows

[Brian Gladman]

On 21/07/2015 10:29, Russell Wallace wrote:
> 2.6.0 used to be quite straightforward to build on Windows; despite the
> references in the documentation to vsyasm, the build procedure actually
> worked fine with plain yasm, which could be placed anywhere in your
> path. Unfortunately 2.6.0 doesn't build with Visual C++ 2015.
>
> 2.7.0 does seem to be compatible with Visual C++ 2015, but unfortunately
> the build batch files seem to be gone, and the new msbuild procedure
> doesn't work with yasm. Presumably I could hack vsyasm Into Visual
> Studio with enough effort, but that doesn't seem to be a repeatable
> procedure, and exceeds the threshold of work that can be expected of
> each user trying to build a program that depends on mpir.

Hi Russell,

Unfortunately the batch file build on Windows was maintained by Jason
Moxham who sadly passed away in 2012. In consequence it had not been
maintained since then and could not therefore be used to build MPIR 2.7.0.

I am puzzled by the problems you have (or foresee) with vsyasm.  It
should be no more difficult to use vsyasm with Visual Studio than it is
to use yasm.  All you have to do for Visual Studio 2015 is to add
vsyasm.exe to the Visual C++ binary directory at:

  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin

after which the Visual Studio builds should work 'out of the box'.

There was a problem with the vsyasm.exe provided on the yasm site but I
believe that Peter Johnson has now solved this.  If it still fails, I
will be happy to send you a version that I know works.

Since you have to put yasm somewhere where Visual Studio can find it,
how is doing this for vsyasm any different?

Can you explain in what way the current Visual Studio builds are not
repeatable?

Maybe I can help you to set up an environment in which these builds will
work for you.

> Is there a way to bring back the ability to use plain yasm, and thus or
> otherwise obtain a repeatable procedure for building mpir?

This could be done but it would need a volunteer to update them for MPIR
2.7.0 and then to maintain them for the future.

best regards

  Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Building MPIR 2.7.0 (alpha11) with VS Express 2013 for Desktop

[Brian Gladman]

On 30/06/2015 14:56, wez...@gmail.com wrote:

> Unfortunately, the error persists. Could you re-upload vsyasm? Right
> now, brgladman.org just shows something about selling vinegar in chinese.

Hi,

I let that domain go as I did not need it - try this download location:

http://173.254.28.24/~brgladma/vsyasm.zip

which is a zipped version of vsyasm.exe (64-bit version).

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: MPIR MinGW installation - "undefined reference to '_imp____gmpz_init'

[Brian Gladman]

On 19/06/2015 15:28, 'Bill Hart' via mpir-devel wrote:

> Anyhow the error message above suggests something is linking against
> MPIR but the linker is somehow looking for an internal symbol (it's
> something to do with the complicated way symbols are handled in MinGW).
> This could be because your system PATH is not set to include the
> directory where the dll file is. 

On Windows it is possible to link directly to a DLL but this is more
normally done through a stub-library.

So on a native build on Windows the mpir.dll is accompanied by the stub
library mpir.lib.  So an app links to the stub library which then links
to the DLL itself.  IIRC a symbol 'sym' in the DLL becomes '__imp__sym'
in the stub library so it seems to me that the mingw/GCC build system is
not producing a stub library.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: MPIR MinGW installation - "undefined reference to '_imp____gmpz_init'

[Brian Gladman]

On 19/06/2015 15:10, highcalcula...@gmail.com wrote:
> Dear All,
> 
> Thanks for your help. I do not see a file exactly called "libmpir.dll",
> so if I really need to have "libmpir.lib" sitting in the .libs folder,
> how would I get the former to convert it via the MS lib tool to the latter?
> I tried to convert the two existing ".dll" files in the .libs folder,
> namely "libmpir-3.dll" and "libmpir-16.dll" via the MS lib tool
> (accessed via cmd) to their respective ".lib" counterparts (eg. using
> this description
> ).
> Then I used "-lmpir-3" resp. "-lmpir-16" in the mex command, which again
> returned the
> "...unresolved external symbol __imp___gmpf_init ..." message.
> Specifically, I used the command
> 
> mex -IC:/MPIR/mpir-2.7.0/ -LC:/MPIR/mpir-2.7.0/.libs/
> -LC:/MPIR/mpir-2.7.0/mpf/.libs -LC:/MPIR/mpir-2.7.0/printf/.libs mexlib.c
> 
> I also tried to add the MPIR root and .libs directories to the LIB and
> INCLUDE variables in the mexopts.bat settings file, which did not help
> anything.
> 
> Rob: The above message, for each mpf_... function, appear if I set the
> -lmpir or -lmpir-16 flag, but also if I don't.
> Just changing the extension of "libmpir.la" to "libmpir.lib" did result
> in a "file corrupt" message after mex, as Bill conjectured.
> 
> Brian: How would I build an MPIR DLL using the native Microsoft and
> Intel compilers? Is this here a necessary extra step?

First you need to install a version of Visual Stduio.  This takes some
time but only has to be done infrewquently.  Visual Studio 2013
Community and Visual Studio 2015 Community RC are both free and MPIR has
build files for both of these 'out of the box'.

You open Visual Studio and load the mpir.sln file, select the version
you want to build (e.g. DLL or Static Library), the architecture (e.g.
Nehalem), the configuration (e.g. x64 and Release) and then select
Build.  After this you can load the mpir-tests.sln file to build and run
the tests.

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: MPIR MinGW installation - "undefined reference to '_imp____gmpz_init'

[Brian Gladman]

On 19/06/2015 11:06, highcalcula...@gmail.com wrote:
> Dear All,
> 
> Now the doc mpir-2.7.0.pdf is loading (Firefox); turning off the virus
> scanner was not changing anything.
> 
> One further question: As I wrote, the gcc compilation now works fine for
> me; however, I would like to call it from Matlab using mex files, and
> there, the compiler complains that it does not see any ".lib" files
> (when compiling with "mex ... -lmpir" it looks for a file "libmpir.lib")
> . Neither do I see any in the MPIR directories.
> 
> Should such files be there after a successful installation? 

No, they have to be built after MPIR has been installed.

They are part of the ouput when an MPIR DLL is built using the native
Microsoft and Intel compilers.

best regards, Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Prebuilt binaries?

[Brian Gladman]

On 08/05/2015 00:05, Dann Corbit wrote:
> After building the debug version of the x64 projects, I get linker errors.
> I have to do a project clean, and then I can debug.
> But then I get linker errors with the release version of the project:
> 46>-- Rebuild All started: Project: mpf.get_si, Configuration: Release 
> x64 --
> 38>  ERROR Last MPIR build was \x64\Debug, not lib\x64\Release
> 40>  ERROR Last MPIR build was \x64\Debug, not lib\x64\Release
> 40>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 40>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code 1.
> 47>-- Rebuild All started: Project: mpf.get_ui, Configuration: Release 
> x64 --
> 38>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 38>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code 1.
> 39>  ERROR Last MPIR build was \x64\Debug, not lib\x64\Release
> 39>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 39>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code 1.
> 9>  ERROR Last MPIR build was \x64\Debug, not lib\x64\Release
> 9>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 9>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code 1.
> 
> Everything is in separate folders (even the header files).
> Why is this strangeness necessary?
> I have never seen any other software behave this way.
> 
> I guess that I can always do a clean and rebuild for the entire solution 
> every time I want to debug or release something, but that seems pretty 
> bizarre.

Hi Dann,

Reflecting on your comment on a new day (I am in the UK and I have been
up all night watching our general election results!), I suspect that you
have misunderstood how the build works.

Once you have built any MPIR library, you can then use it to build,
debug and/or release any application that depends on it with no need
whatsoever to rebuild the MPIR library you are using. As you say, each
library configuration is placed in a separate subdirecctory so, as you
rightly expect, each configuration can be frrely used with no need to
rebuild it unless you have changed the MPIR source code in some way.

It is only when you wish to run the _test_ suite that you may need to do
an MPIR rebuild.  This is because the test suite is a separate build
project and it has to be told which MPIR library configuration it should
test (LIB|DLL, Release|Debug, Win32|x64) since any or all of the eight
different configurations may exist.

This is done by assuming that the test suite is run against the last
library configuration that has been built (when a library configuration
is built it writes a file 'output_params.bat' that the tests then use to
check if the test suite is configured correctly to test this version).

But I stress that this _only_ applies to the running of the test suite.
Moreover, you can change this if you wish to by editing
'output_params.bat' as explained in the readme.txt file.

I hope this helps you to understand how the MPIR build works.

I shoud also mention that I have Visual Studio build projects for MPFR
and MPC but those on my web site are out of date so I will need to
update them (or send them to you) if you would like to use them.

The other thing I should mention is that Microsoft is now releasing a
fully featured version of Visual Studio called Visual Studio Community,
which is completely free for open source use.  Visual Studio 2013
Community and Visual Studio 2015 Community RC have now been released and
I am now using the latter for all ongoing MPIR development of MPIR on
Windows.

   with my regards,

 Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Prebuilt binaries?

[Brian Gladman]

On 08/05/2015 00:05, Dann Corbit wrote:
> After building the debug version of the x64 projects, I get linker errors.
> I have to do a project clean, and then I can debug.
> But then I get linker errors with the release version of the project:
> 46>-- Rebuild All started: Project: mpf.get_si, Configuration: Release 
> x64 --
> 38>  ERROR Last MPIR build was \x64\Debug, not lib\x64\Release
> 40>  ERROR Last MPIR build was \x64\Debug, not lib\x64\Release
> 40>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 40>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code 1.
> 47>-- Rebuild All started: Project: mpf.get_ui, Configuration: Release 
> x64 --
> 38>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 38>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code 1.
> 39>  ERROR Last MPIR build was \x64\Debug, not lib\x64\Release
> 39>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 39>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code 1.
> 9>  ERROR Last MPIR build was \x64\Debug, not lib\x64\Release
> 9>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 9>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code 1.
> 
> Everything is in separate folders (even the header files).
> Why is this strangeness necessary?
> I have never seen any other software behave this way.

The tests have to be set up to pick up one specific configuration and it
is (in my view at least) sensible to assume that the user wants to test
the version that was the last one that they built. The design is hence
based on this method of working:

1. Build a specific configuration
2. Test _this_ configuration
3  Repeat for other configurations if needed

But it is easy to build multiple configurations and then edit
output_params.bat to test a specific configuration - this is explained
in the readme.txt file.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Prebuilt binaries?

[Brian Gladman]

On 07/05/2015 23:53, Dann Corbit wrote:
> Hi Dann,
> 
[snip]
>> so I opened the vcxproj and built it from that. Successful.
> 
> It seems that this is the problem.
> The solution does some sort of post-build step to move the library to a 
> non-standard location.
> The other projects expect the library to reside there.
> 
> I think that the mystery is solved.
> 
> It might be nice in the notes to say:
> Using the MPIR solution
> 1. Build for your platform the mpir library and/or the mpir dll files
> 2. Build the mpirxx library.
> 
> I saw the error and built it, but it has to be built from the MPIR solution 
> or it does not work.

It should build from the .vcxproj file since building from the .sln file
does not (AFAIK) impact on a project build.  So this is still a puzzle.

I will add a sentence under 'The Tests' as follows:


The Tests
=

There is a separate solution for the MPIR tests: mpir-tests.sln. In
Visual Studio 2013 this is in build.vc14 folder.  To run the tests
it is important that both mpir.lib (the C library) and mpirxx.lib
(the C++ library) are built prior to building the tests themselves.

   Brian

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Prebuilt binaries?

[Brian Gladman]

On 07/05/2015 23:33, Dann Corbit wrote:
> -Original Message-
> From: mpir-devel@googlegroups.com [mailto:mpir-devel@googlegroups.com] On 
> Behalf Of Brian Gladman
> Sent: Thursday, May 7, 2015 3:09 PM
> To: mpir-devel@googlegroups.com
> Subject: Re: [mpir-devel] Prebuilt binaries?
> 
> On 07/05/2015 21:34, Dann Corbit wrote:
>> I cannot build MPIR (any version) on my machine now with Visual Studio 
>> 2013.  I can build it with Mingw, but I want to use Visual Studio 
>> since development is easier for me in that environment (I like the 
>> debugger better, etc.)
> 
> Hi Dann,
> 
> I have tested the MPIR builds for Visual Studio 2012, 2013 and 2015 and they 
> all work for me so I am at a bit of a loss about the failure you are seeing.
> 
> Can I ask what happens when you try to build it?  What output do you get from 
> Visual Studio during the build?
> 
> Have you tried a clean build from the newly downloaded repository version of 
> MPIR?
> 
>>>
> OK.
> I pulled all the current source from the git repository.
> I was building for core2, but I figured out that I really need to build for 
> sandybridge (I have Intel® Xeon® Processor E5-1650).
> 
> Steps I took.
> 1. Pull new instance of repository
> 2. Load mpir project
> 3.  Build for sandybridge
> 4.  Load mpir-tests project
> 5. Wait until all the "initializing" things go away
> 6. Try to build the tests.
> 7. Abject failure.
> 
> When I build the MPIR library everything looks happy:
> ...
> lib_mpir_sandybridge.vcxproj -> 
> F:\math\mpir-master\build.vc12\x64\Release\mpir.lib
> 1>  copying outputs from "x64\Release" to "..\lib\x64\Release"
> 
> Until I try to use it, at which point I get a giant pile of this stuff:
> 1>-- Build started: Project: add-test-lib, Configuration: Release x64 
> --
> 2>-- Build started: Project: mpn.mullow_basecase, Configuration: Release 
> x64 --
> 3>-- Build started: Project: mpn.mulmid, Configuration: Release x64 --
> 4>-- Build started: Project: mpn.subadd_n, Configuration: Release x64 
> --
> 5>-- Build started: Project: mpn.mullowhigh, Configuration: Release x64 
> --
> 6>-- Build started: Project: mpf.eq, Configuration: Release x64 --
> 7>-- Build started: Project: mpn.neg, Configuration: Release x64 --
> 8>-- Build started: Project: mpn.mulmod_2expm1, Configuration: Release 
> x64 --
> 9>-- Build started: Project: mpz.trial_division, Configuration: Release 
> x64 --
> 10>-- Build started: Project: mpn.sb_divappr_q, Configuration: Release 
> x64 --
> 11>-- Build started: Project: mpz.likely_prime_p, Configuration: Release 
> x64 --
> 12>-- Build started: Project: mpn.inv_div_q, Configuration: Release x64 
> --
> 1>EXEC : error : static library tests need 'mpirxx.lib'
> 1>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 1>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code -1.
> 2>EXEC : error : static library tests need 'mpirxx.lib'
> 2>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 2>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code -1.
> 4>EXEC : error : static library tests need 'mpirxx.lib'
> 4>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 4>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code -1.
> 
> Pages and pages and pages with more of the same.  At the bottom, it looks 
> like this:
> 
> 201>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: The command "..\check_config x64 Release
> 201>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): 
> error MSB3073: :VCEnd" exited with code -1.
> == Build: 0 succeeded, 202 failed, 0 up-to-date, 0 skipped ==
> 
> Seems obvious, I need to build mpirxx.lib
> It does not have a solution, so I opened the vcxproj and built it from that. 
> Successful.

Hi again Dann,

I am sorry I mis