Digraphs on windows compiles to .dll and not to .so #177

olexandr-konovalov · 2019-03-09T00:59:47Z

I still can not provide a working version of digraphs (and hence semigroups, which needs it) for GAP 4.10.1. It compiles to bin/i686-pc-cygwin-default32-kv3/digraphs.dll while its AvailabilityTest checks for digraphs.so.

Furthermore, this happens if I edit AvailabilityTest to check for digraphs.dll:

gap> LoadPackage("dig");
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Loading  orb 4.8.2 (Methods to enumerate orbits)
by Juergen Mueller (http://www.math.rwth-aachen.de/~Juergen.Mueller),
   Max Neunhöffer (http://www-groups.mcs.st-and.ac.uk/~neunhoef), and
   Felix Noeske (http://www.math.rwth-aachen.de/~Felix.Noeske).
Homepage: https://gap-packages.github.io/orb
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Loading  GRAPE 4.8.1 (GRaph Algorithms using PErmutation groups)
by Leonard H. Soicher (http://www.maths.qmul.ac.uk/~lsoicher/).
Homepage: https://gap-packages.github.io/grape
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Error, Variable: 'IS_MULTI_DIGRAPH' must have a value
not in any function at /proc/cygdrive/C/gap-4.10.1/pkg/digraphs-0.15.0/gap/digraph.gi:525
Error, was not in any namespace at /proc/cygdrive/C/gap-4.10.1/lib/variable.g:291 called from
LEAVE_NAMESPACE(  ); at /proc/cygdrive/C/gap-4.10.1/lib/package.gi:1253 called from
<function "ReadPackage">( <arguments> )
 called from read-eval loop at /proc/cygdrive/C/gap-4.10.1/pkg/digraphs-0.15.0/read.g:26
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk>

The text was updated successfully, but these errors were encountered:

wilfwilson · 2019-03-12T08:06:22Z

@james-d-mitchell Any idea what we can do about this?

james-d-mitchell · 2019-03-12T09:43:39Z

@alex-konovalov @wilfwilson I don't really know what the problem is. Is this issue new, or did it always exist? I just had a look at the IO setup, for example, and it seems to be the same as Digraphs. Does IO work as expected on Windows? @ChrisJefferson @fingolfin any suggestions?

olexandr-konovalov · 2019-03-12T09:51:04Z

I haven't seen this before - prior to that, the build failed at an earlier stage as described in #138.

The IO package compiles to io.so, to the contrary.

james-d-mitchell · 2019-03-12T09:53:50Z

Ah, so what happens if you simply rename digraphs.dll to digraphs.so, I mean the actual executable?

james-d-mitchell · 2019-03-12T09:54:24Z

And sorry for not being more help, I don't have access to a windows computer so can't experiment.

james-d-mitchell · 2019-03-12T09:55:51Z

In IO's Makefile.am:

GAPINSTALLLIB = $(BINARCHDIR)/io.so
[....]
if SYS_IS_CYGWIN
	cp .libs/io.dll $(GAPINSTALLLIB)
else
	cp .libs/io.so $(GAPINSTALLLIB)
endif

In Digraphs,

GAPINSTALLLIB = $(abs_top_srcdir)/$(BINARCHDIR)/
[...]
if SYS_IS_CYGWIN
	cp .libs/digraphs.dll $(GAPINSTALLLIB)
else
	cp .libs/digraphs.so $(GAPINSTALLLIB)
endif

james-d-mitchell · 2019-03-12T09:56:24Z

So, it looks like in IO the .dll is simply renamed .so.

wilfwilson · 2019-03-12T10:28:49Z

Yes, in the io Makefile.am there is

BINARCHDIR = bin/$(GAPARCH)
GAPINSTALLLIB = $(BINARCHDIR)/io.so

so the command

cp .libs/io.dll $(GAPINSTALLLIB)

simply copies the dll to the same directory as usual, but renames it as io.so. But in Digraphs:

BINARCHDIR = bin/$(GAPARCH)
GAPINSTALLLIB = $(abs_top_srcdir)/$(BINARCHDIR)/

and so cp .libs/digraphs.dll $(GAPINSTALLLIB) is not renaming the .dll.

And is perhaps Digraphs putting the dll in the wrong place @james-d-mitchell? Note that GAPINSTALLLIB is defined differently in Digraphs compared with io. (No, because then it wouldn't work on Unix either...)

wilfwilson · 2019-03-12T10:29:41Z

(Sorry James I've repeated what you wrote, just wanted to look at it myself)

wilfwilson · 2019-03-12T11:05:55Z

I got access to a Windows machine and installed GAP 4.10.1 through the exe installer. I then renamed the .dll to .so:

 ┌───────┐   GAP 4.10.1 of 23-Feb-2019
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: i686-pc-cygwin-default32-kv3
 Configuration:  gmp 6.1.2, readline
 Loading the library and packages ...
 Packages:   AClib 1.3.1, Alnuth 3.1.0, AtlasRep 1.5.1, AutoDoc 2019.02.22,
             AutPGrp 1.10, Browse 1.8.8, CRISP 1.4.4, Cryst 4.1.18,
             CrystCat 1.1.8, CTblLib 1.2.2, FactInt 1.6.2, FGA 1.4.0,
             GAPDoc 1.6.2, IO 4.5.4, IRREDSOL 1.4, LAGUNA 3.9.2, Polenta 1.3.8,
             Polycyclic 2.14, PrimGrp 3.3.2, RadiRoot 2.8, ResClasses 4.7.1,
             SmallGrp 1.3, Sophus 1.24, SpinSym 1.5, TomLib 1.2.7,
             TransGrp 2.0.4, utils 0.61
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'
gap> LoadPackage("io");
true
gap> LoadPackage("digraphs");
───────────────────────────────────────────────────────────────────────────────
Loading  orb 4.8.2 (Methods to enumerate orbits)
by Juergen Mueller (http://www.math.rwth-aachen.de/~Juergen.Mueller),
   Max Neunhöffer (http://www-groups.mcs.st-and.ac.uk/~neunhoef), and
   Felix Noeske (http://www.math.rwth-aachen.de/~Felix.Noeske).
Homepage: https://gap-packages.github.io/orb
───────────────────────────────────────────────────────────────────────────────
───────────────────────────────────────────────────────────────────────────────
Loading  GRAPE 4.8.1 (GRaph Algorithms using PErmutation groups)
by Leonard H. Soicher (http://www.maths.qmul.ac.uk/~lsoicher/).
Homepage: https://gap-packages.github.io/grape
───────────────────────────────────────────────────────────────────────────────
#W dlopen() error: No such file or directory
Error, module '/proc/cygdrive/C/gap-4.10.1/pkg/digraphs-0.15.0/bin/i686-pc-cygwin-defau\
lt32-kv3/digraphs.so' not found in
  if not LOAD_DYN( arg[1], false ) then
    Error( "no support for dynamic loading" );
fi; at /proc/cygdrive/C/gap-4.10.1/lib/files.gd:583 called from
<function "LoadDynamicModule">( <arguments> )
 called from read-eval loop at /proc/cygdrive/C/gap-4.10.1/pkg/digraphs-0.15.0/init.g:25
Error, was not in any namespace at /proc/cygdrive/C/gap-4.10.1/lib/variable.g:291 called from
LEAVE_NAMESPACE(  ); at /proc/cygdrive/C/gap-4.10.1/lib/package.gi:1253 called from
ReadPackage( pkgname, "init.g"
 ); at /proc/cygdrive/C/gap-4.10.1/lib/package.gi:1616 called from
<function "LoadPackage">( <arguments> )
 called from read-eval loop at *stdin*:2
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk>

wilfwilson · 2019-03-12T11:10:07Z

Note that the file really does seem to exist:

gap> IO_File("/proc/cygdrive/C/gap-4.10.1/pkg/digraphs-0.15.0/bin/i686-pc-cygwin-default32-kv3/digraphs.so");
<file fd=6 rbufsize=65536 rpos=1 rdata=0>

(i.e. it doesn't fail)

james-d-mitchell · 2019-03-12T11:15:05Z

What happens when you do:

  LoadDynamicModule(Filename(DirectoriesPackagePrograms("io"),
                             "io.so"));

wilfwilson · 2019-03-12T11:19:11Z

I can't tell you right now because that GAP installation broke somehow. I'll reinstall at some point. But everything I tried to do with IO seemed to work fine - and I think I tried that command (although maybe not fine, since I think I had already loaded IO at that point, but it didn't have the Digraphs error anyway).

james-d-mitchell · 2019-03-12T11:19:12Z

# load kernel function if it is installed:
if (not IsBound(DIGRAPHS_C)) and ("digraphs" in SHOW_STAT()) then
  # try static module
  LoadStaticModule("digraphs");
fi;
if (not IsBound(DIGRAPHS_C)) and
    (Filename(DirectoriesPackagePrograms("digraphs"), "digraphs.so") <> fail)
    then
  LoadDynamicModule(Filename(DirectoriesPackagePrograms("digraphs"),
                             "digraphs.so"));
fi;

Looking at this again it looks like DIGRAPHS_C is not defined anywhere. I'm not sure that this is related, but it seems strange to check for DIGRAPHS_C if it never exists.

wilfwilson · 2019-03-12T11:22:11Z

I feel like it used to exist. But it's probably not relevant here.

james-d-mitchell · 2019-03-12T11:24:04Z

So, the question is: is "digraphs" in SHOW_STAT() on windows? If it is, and the module is loaded by LoadStaticModule then since DIGRAPHS_C is not defined anywhere tries to load the module again using LoadDynamicModule, could be the source of the problem?

james-d-mitchell · 2019-03-12T11:24:20Z

I'm sure it used to exist

wilfwilson · 2019-03-12T12:04:34Z

 ┌───────┐   GAP 4.10.1 of 23-Feb-2019
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: i686-pc-cygwin-default32-kv3
 Configuration:  gmp 6.1.2, readline
 Loading the library and packages ...
 Packages:   AClib 1.3.1, Alnuth 3.1.0, AtlasRep 1.5.1, AutoDoc 2019.02.22, AutPGrp 1.10, Browse 1.8.8, CRISP 1.4.4,
             Cryst 4.1.18, CrystCat 1.1.8, CTblLib 1.2.2, FactInt 1.6.2, FGA 1.4.0, GAPDoc 1.6.2, IO 4.5.4,
             IRREDSOL 1.4, LAGUNA 3.9.2, Polenta 1.3.8, Polycyclic 2.14, PrimGrp 3.3.2, RadiRoot 2.8,
             ResClasses 4.7.1, SmallGrp 1.3, Sophus 1.24, SpinSym 1.5, TomLib 1.2.7, TransGrp 2.0.4, utils 0.61
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'
gap> SHOW_STAT();
[ "GAPROOT/lib/type1.g", -43167549, "GAPROOT/lib/oper1.g", 32938550 ]
gap>

wilfwilson · 2019-03-12T12:07:54Z

And then to answer your earlier question, immediately after my previous comment:

gap> LoadDynamicModule(Filename(DirectoriesPackagePrograms("io"),
>                              "io.so"));
Duplicate cookie src/io.c:IO_open
Duplicate cookie src/io.c:IO_creat
Duplicate cookie src/io.c:IO_read
Duplicate cookie src/io.c:IO_write
Duplicate cookie src/io.c:IO_close
Duplicate cookie src/io.c:IO_lseek
Duplicate cookie src/io.c:IO_opendir
Duplicate cookie src/io.c:IO_readdir
Duplicate cookie src/io.c:IO_rewinddir
Duplicate cookie src/io.c:IO_closedir
Duplicate cookie src/io.c:IO_telldir
Duplicate cookie src/io.c:IO_seekdir
Duplicate cookie src/io.c:IO_unlink
Duplicate cookie src/io.c:IO_link
Duplicate cookie src/io.c:IO_rename
Duplicate cookie src/io.c:IO_symlink
Duplicate cookie src/io.c:IO_readlink
Duplicate cookie src/io.c:IO_mkdir
Duplicate cookie src/io.c:IO_chdir
Duplicate cookie src/io.c:IO_getcwd
Duplicate cookie src/io.c:IO_rmdir
Duplicate cookie src/io.c:IO_stat
Duplicate cookie src/io.c:IO_fstat
Duplicate cookie src/io.c:IO_lstat
Duplicate cookie src/io.c:IO_chmod
Duplicate cookie src/io.c:IO_fchmod
Duplicate cookie src/io.c:IO_chown
Duplicate cookie src/io.c:IO_fchown
Duplicate cookie src/io.c:IO_lchown
Duplicate cookie src/io.c:IO_mknod
Duplicate cookie src/io.c:IO_mkstemp
Duplicate cookie src/io.c:IO_mkdtemp
Duplicate cookie src/io.c:IO_mkfifo
Duplicate cookie src/io.c:IO_dup
Duplicate cookie src/io.c:IO_dup2
Duplicate cookie src/io.c:IO_socket
Duplicate cookie src/io.c:IO_bind
Duplicate cookie src/io.c:IO_connect
Duplicate cookie src/io.c:IO_make_sockaddr_in
Duplicate cookie src/io.c:IO_gethostbyname
Duplicate cookie src/io.c:IO_listen
Duplicate cookie src/io.c:IO_accept
Duplicate cookie src/io.c:IO_recv
Duplicate cookie src/io.c:IO_recvfrom
Duplicate cookie src/io.c:IO_send
Duplicate cookie src/io.c:IO_sendto
Duplicate cookie src/io.c:IO_getsockopt
Duplicate cookie src/io.c:IO_setsockopt
Duplicate cookie src/io.c:IO_select
Duplicate cookie src/io.c:IO_IgnorePid
Duplicate cookie src/io.c:IO_WaitPid
Duplicate cookie src/io.c:IO_fork
Duplicate cookie src/io.c:IO_execv
Duplicate cookie src/io.c:IO_execvp
Duplicate cookie src/io.c:IO_execve
Duplicate cookie src/io.c:IO_environ
Duplicate cookie src/io.c:IO_InstallSIGCHLDHandler
Duplicate cookie src/io.c:IO_RestoreSIGCHLDHandler
Duplicate cookie src/io.c:IO_pipe
Duplicate cookie src/io.c:IO_exit
Duplicate cookie src/io.c:IO_fcntl
Duplicate cookie src/io.c:IO_getpid
Duplicate cookie src/io.c:IO_getppid
Duplicate cookie src/io.c:IO_kill
Duplicate cookie src/io.c:IO_gettimeofday
Duplicate cookie src/io.c:IO_gmtime
Duplicate cookie src/io.c:IO_localtime
Duplicate cookie src/io.c:IO_getsockname
Duplicate cookie src/io.c:IO_gethostname
Error, Variable: 'IO_open' is read only
not in any function at *stdin*:3
you can 'return;' after making it writable
brk>

james-d-mitchell · 2019-03-12T12:08:52Z

And when you do:

LoadDynamicModule(Filename(DirectoriesPackagePrograms("digraphs"), "digraphs.so"));

explicitly?

wilfwilson · 2019-03-12T12:12:54Z

Same again unfortunately:

gap> LoadDynamicModule(Filename(DirectoriesPackagePrograms("digraphs"), "digraphs.so"));
#W dlopen() error: No such file or directory
Error, module '/proc/cygdrive/C/gap-4.10.1/pkg/digraphs-0.15.0/bin/i686-pc-cygwin-default32-kv3/digraphs.so' not found in
  if not LOAD_DYN( arg[1], false ) then
    Error( "no support for dynamic loading" );
fi; at /proc/cygdrive/C/gap-4.10.1/lib/files.gd:583 called from
<function "LoadDynamicModule">( <arguments> )
 called from read-eval loop at *stdin*:1
gap>

james-d-mitchell · 2019-03-12T12:14:03Z

And the file /proc/cygdrive/C/gap-4.10.1/pkg/digraphs-0.15.0/bin/i686-pc-cygwin-default32-kv3/digraphs.so definitely exists and is readable?

ChrisJefferson · 2019-03-12T12:14:31Z

I'm looking at this.

It seems to be looking for a file called "cygplanarity". Does the name ring any bells (maybe using a library called planarity?)

james-d-mitchell · 2019-03-12T12:15:21Z

Thanks @ChrisJefferson, yeah, I guess that cygplanarity is related to the subpackage edge-planarity-suite.

james-d-mitchell · 2019-03-12T12:17:04Z

which is contained in the extern directory of the digraphs folder

wilfwilson · 2019-03-12T12:19:44Z

I'll note that digraphs (unlike io) also has a bin/libs folder, containing

09.03.2019  06:25           297.976 cygplanarity-0.dll
09.03.2019  06:25           190.738 libplanarity.a
09.03.2019  06:25           227.690 libplanarity.dll.a
09.03.2019  06:25             1.009 libplanarity.la
09.03.2019  06:25             1.017 libplanarity.lai
09.03.2019  06:25            29.667 lt-planarity.c
09.03.2019  06:25           173.436 planarity.exe
09.03.2019  06:25             6.668 planarity_ltshwrapper

In particular there's a cygplanarity-0.dll here

ChrisJefferson · 2019-03-12T12:23:01Z

The list of places that GAP series for dlls is unfortunately not super useful.

It will look in the \lib or \bin directory of your cygwin install, or in the '.libs' directory of the GAP install. It doesn't look anywhere inside the digraphs directory.

wilfwilson · 2019-03-12T12:32:20Z

@alex-konovalov This seems to work, I think 🙂

wilfwilson · 2019-03-12T12:40:08Z

@ChrisJefferson Do you think all of the files from the digraphs/bin/libs folder listed in #177 (comment) need to be copies to the GAP root .libs, or just the dll? And do you think anything from the extern folder should be copied?

Similarly, for semigroups, I can see that there is a semigroups-3.1.1/.libs folder, containing files none of which are in GAPROOT/.libs. There is a semigroups-3.1.1/bin/lib folder, and only cygsemigroups-0.dll from there is in GAPROOT/.libs, but not various files like libsemigroups.a. Does this sound right?

ChrisJefferson · 2019-03-12T12:41:03Z

You only need to copy dll files which are required by the dlls (renamed so) that you explictly load.

ChrisJefferson · 2019-03-12T12:41:40Z

Which tests don't pass? I just ran testinstall.tst from digraphs and it works fine (although I'm in a "full" cygwin install, so the problem could be how we package it)

wilfwilson · 2019-03-12T12:41:43Z

Thanks.

wilfwilson · 2019-03-12T12:42:29Z

Try DigraphsTestStandard(); @ChrisJefferson - for me it crashes and closes the window when it gets to io.tst.

wilfwilson · 2019-03-12T12:43:01Z

SemigroupsTestInstall(); also fails, but thankfully doesn't crash.

ChrisJefferson · 2019-03-12T13:01:39Z

Amusingly (well, the coincidence is amusing), this was just fixed by @embray's patch gap-system/gap#3335

ChrisJefferson · 2019-03-12T13:03:24Z

both digraphs and semigroups tests pass on my computer with that patch applied and the two dlls (one for semigroups, one for digraphs) copied into GAP's .libs directory (and digraph's .dll renamed to .so).

james-d-mitchell · 2019-03-12T13:06:46Z

Nice

wilfwilson · 2019-03-12T13:10:10Z

@ChrisJefferson which was the semigroups dll that you copied to GAP's .libs directory, which wasn't already there?

embray · 2019-03-12T13:14:05Z

Is there anything I might be able to do to help here? If the Digraphs package uses autoconf and libtool it can be configured to output DLLs correctly.

To be clear though, the runtime link path for DLLs is the same as your $PATH variable, though it will also first look relative to the executable that's loading the DLL.

I think that in Sage's installation of GAP I've made sure that compiled GAP packages can be loaded properly in general, though I'm not sure if I've tried the digraphs package (nor do I fully understand why it would be different or special).

james-d-mitchell · 2019-03-12T13:25:47Z

We are using autoconf and libtool, I don't think Digraphs is special, or different, but none of its developers are using Windows, so we may have unintentionally failed to do something correctly in the setup. Hopefully this is resolved by @wilfwilson PR #178 ?

ChrisJefferson · 2019-03-12T14:55:13Z

Technically, rather than rename the dll, digraph's init.g could be changed to load a .dll if it's in windows, and a .so if it's in linux, but I'm not convinced that makes things easier/clearer personally.

Getting the second dll (cygplanarity-0.dll) to load is trickier, as that is autoloaded by windows as a requirement of the digraph dll, so we need to put it somewhere (like .libs) where windows will look for it.

embray · 2019-03-12T15:08:16Z

It's not actually tricky necessarily. The problem I'm struggling, which I don't understand, is how GAP searches for compiled packages e.g. on Linux. It seems with most packages if I run make in the package's source tree, it creates its own bin/ directory inside the package sources, as opposed to say the $(GAPROOT)/bin. How are all these bin/ directories collected up "normally" e.g. on Linux?

embray · 2019-03-12T15:10:05Z

Also, confusingly, if I run make install for Digraph it just installed everything to a random-seeming ../../bin, rather than ../../gap/bin (where ../../gap was the path I gap for --with-gaproot=../../gap).

embray · 2019-03-12T15:12:54Z

I see. In the configure.ac for Digraph it has AC_PREFIX_DEFAULT('${abs_top_builddir}/../../bin/'). This should probably be relative to GAPROOT and not just assume that that would be ../../ (I'm not building with the package sources inside my GAPROOT directory).

ChrisJefferson · 2019-03-12T16:40:04Z

Nothing in gap had a working make install, and nothing is intended to be moved after it is built (other than copying the whole build tree) . A Gap just runs pkg binaries from where they are built.

ChrisJefferson · 2019-03-12T19:39:31Z

At the moment, when we distribute GAP on Cygwin we try to include the minimal pieces of Cygwin needed. I think that's just causing trouble, so in the next release I plan on including the complete minimal installation of Cygwin. This will make things easier as we can just copy these dlls into /lib.

embray · 2019-03-13T15:07:18Z

After thinking about this some more, I'm starting to realize that I think something GAP could use is a GAP-level interface to dlopen(). Because what I really want to be able to do to solve this problem is to explicitly dlopen() the libplanarity used by the digraphs package. One reason being I already have a libplanarity installed on my system, and if the digraphs package wants to use a specific one, it really should probably dlopen() it directly into the GAP executable. Alternatively, the Digraph package itself could dlopen() the appropriate libplanarity.so relative to its own path.

That way there would be less need for mucking around with rpaths, or making sure x file is in y directory.

Otherwise I think the best alternative, at least on Windows, is for the package's init.g to set $PATH (at least temporarily) so that the path to the cygplanarity-0.dll leads the path (it can then drop it again once the DLL is loaded).

embray · 2019-03-13T15:20:15Z

I should add, in the above case, it should also be easy to disable this in case a downstream packager (e.g. on Debian) would like to use the system's libplanarity instead, so long as it's compatible.

Another alternative that might be still even simpler, since Digraphs is already vendoring libplanarity, would be to statically link it--or even just the parts of it needed by Digraphs--into the digraphs.so module. I have done the same, for example, in several Python extension modules. Though in this case it might be advisable to also prefix any libplanarity symbols.

james-d-mitchell · 2019-03-13T19:52:53Z

Thanks @embray, how do we statically link libplanarity into Digraphs.so?

wilfwilson · 2019-03-26T11:17:22Z

I will close this issue now. The fix to the issue is contained in v0.15.1. If there comes some improvement to the way that GAP works with respect to cygwin, then I'll be happy to make further changes. But for now, I think we've resolved the issue as well as we reasonably can.

james-d-mitchell · 2019-06-17T13:15:20Z

I'm going to re-open this in the hope that Erik and I can find a "proper" solution, since Erik and I are in the same room currently.

olexandr-konovalov · 2019-06-21T13:15:57Z

This works in GAP 4.10.2 release candidate:

gap> LoadPackage("digraphs");
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Loading  GRAPE 4.8.2 (GRaph Algorithms using PErmutation groups)
by Leonard H. Soicher (http://www.maths.qmul.ac.uk/~lsoicher/).
Homepage: https://gap-packages.github.io/grape
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Loading  Digraphs 0.15.2 (Digraphs - Methods for digraphs)
by Jan De Beule (http://homepages.vub.ac.be/~jdbeule/),
   Julius Jonusas (http://www-groups.mcs.st-andrews.ac.uk/~julius/),
   James Mitchell (http://goo.gl/ZtViV6),
   Michael Torpey (http://www-groups.mcs.st-andrews.ac.uk/~mct25/), and
   Wilf Wilson (http://wilf.me).
Homepage: https://gap-packages.github.io/Digraphs
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
true
gap> TestPackage("digraphs");
Digraphs package: testinstall.tst
msecs: 63
#I  No errors detected while testing package digraphs version 0.15.2
#I  using the test file `/proc/cygdrive/C/gap-4.10.2/pkg/digraphs-0.15.2/tst/testinstall.tst'
gap>

so perhaps can be closed, unless you have further plans to improve something.

olexandr-konovalov mentioned this issue Mar 9, 2019

Problem in installing semigroups package on windows semigroups/Semigroups#573

Closed

james-d-mitchell added bug A label for issues that are bugs major A label for PRs or issues that are major in some sense. labels Mar 12, 2019

wilfwilson mentioned this issue Mar 12, 2019

Fix Digraphs for cygwin #178

Merged

wilfwilson changed the title ~~DIgraphs on windows compiles to .dll and not to .so~~ Digraphs on windows compiles to .dll and not to .so Mar 26, 2019

wilfwilson closed this as completed Mar 26, 2019

james-d-mitchell reopened this Jun 17, 2019

wilfwilson closed this as completed Oct 17, 2019

Digraphs on windows compiles to .dll and not to .so #177

Digraphs on windows compiles to .dll and not to .so #177

Comments

olexandr-konovalov commented Mar 9, 2019

wilfwilson commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

olexandr-konovalov commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

wilfwilson commented Mar 12, 2019 • edited Loading

wilfwilson commented Mar 12, 2019 • edited Loading

wilfwilson commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

wilfwilson commented Mar 12, 2019 • edited Loading

james-d-mitchell commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

ChrisJefferson commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

wilfwilson commented Mar 12, 2019 • edited Loading

ChrisJefferson commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

ChrisJefferson commented Mar 12, 2019

ChrisJefferson commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

ChrisJefferson commented Mar 12, 2019

ChrisJefferson commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

wilfwilson commented Mar 12, 2019

embray commented Mar 12, 2019

james-d-mitchell commented Mar 12, 2019

ChrisJefferson commented Mar 12, 2019

embray commented Mar 12, 2019

embray commented Mar 12, 2019

embray commented Mar 12, 2019

ChrisJefferson commented Mar 12, 2019 • edited Loading

ChrisJefferson commented Mar 12, 2019

embray commented Mar 13, 2019

embray commented Mar 13, 2019

james-d-mitchell commented Mar 13, 2019

wilfwilson commented Mar 26, 2019

james-d-mitchell commented Jun 17, 2019

olexandr-konovalov commented Jun 21, 2019

wilfwilson commented Mar 12, 2019 •

edited

Loading

wilfwilson commented Mar 12, 2019 •

edited

Loading

wilfwilson commented Mar 12, 2019 •

edited

Loading

wilfwilson commented Mar 12, 2019 •

edited

Loading

ChrisJefferson commented Mar 12, 2019 •

edited

Loading