Hi Brian, Isuru Fernando believes he may have found the issue. I'll try reinserting the export as soon as we fix some other issues and see if it passes again.
For example, the fmpz_poly_factor test hangs at present. We haven't been able to figure out why. We are using MSVC files built by CMake I think. So we don't need the ones from your repository for our CI (I think). (To be honest I am a bit lost with the current Windows maintenance, as others have largely been doing it for me. For example I just learned that they had disabled some of the tests in the CI because they were hanging or crashing. We are now down to one of each.) Best Wishes, Bill. On Tue, 21 Apr 2020 at 09:56, Cactus <rieman...@gmail.com> wrote: > > > On Tuesday, 21 April 2020 00:28:28 UTC+1, Bill Hart wrote: >> >> Hi Brian, >> >> After making these changes, our cmake continuous integration fails. I >> think the problem is with this line: >> >> FLINT_DLL const unsigned int partitions_lookup[128]; >> >> Is this only relevant for MSVC? >> >> Bill. >> > > Good morning Bill, > > Unless something strange is going on, an Arb DLL, when built to import > from a FLINT DLL, will require that this symbol is exported when the flint > DLL is built. > > So the need for this symbol is not unique to MSVC but the mechanism for > exporting it using the FLINT_DLL defines in source code is MSVC specific. > > I believe that CMake builds flint on Windows using my flint MSVC build > files. But my guess is that it doesn't use my build system to regenerate > these files when the build is updated (as in this case). > > If I am right about this, CMake may simply be failing because it is now > using the old MSVC build files. > > Regenerating these build files or importing them from my flint repository > may hence fix this issue (assuming that my repository is still in sync with > the master repository). > > Brian > > >> On Tue, 21 Apr 2020 at 00:37, Bill Hart <goodwi...@googlemail.com> wrote: >> >>> Hi Brian, >>> >>> I have fixed the three issues you pointed out to do with building an Arb >>> dll. Thanks very much for pointing these out. >>> >>> As for the flint dll, I don't mind what name is used. It's not a problem >>> for me. This is technically flint2, not flint. But it is very many years >>> since anyone has used the latter. I think it is fine to simply call it >>> flint now. >>> >>> Bill. >>> >>> >>> On Tue, 14 Apr 2020 at 19:55, Brian Gladman <riem...@gmail.com> wrote: >>> >>>> 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-...@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 >>>> . >>>> >>> -- > 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/8e593b67-2c8d-4285-beef-03795e087f6a%40googlegroups.com > <https://groups.google.com/d/msgid/mpir-devel/8e593b67-2c8d-4285-beef-03795e087f6a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAB0xFntHfCH36oqWS3abK8PTWqNeOXJoM11qquSDdTVZ-DqrKQ%40mail.gmail.com.
