Isuru reinserted the necessary line FLINT_DLL const unsigned int partitions_lookup[128];
Perhaps you could check if this works for you now. Bill. On Tue, 21 Apr 2020 at 17:26, Bill Hart <goodwillh...@googlemail.com> wrote: > 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/CAB0xFnseqa%2Brom1ozEZfr-iYv_Yy18rcQySdrEycRoK-MudTTg%40mail.gmail.com.
