Bug#736398: gap-dev: multi-architecture support
On Sat, Jul 05, 2014 at 01:43:10PM +0200, Bill Allombert wrote: AC_FIND_GAP is used by some GAP package, so the issue does not concern only GAP-IO. Even if I am agree to say that the implemented location of gmp.h is weak, it seems nevertheless that an external include hierarchy is expected in `/usr/lib/gap/bin/GAP triplet/extern'. If this assertion is true, then the --with-gmp=system in GAP does not complete its jobs properly, so it might be a bug in the GAP source itself --- after all, it is GAP itself that may point the GMP material with which it was built. I do not see how gap can generate the extern hierarchy when using --with-gmp=system and doing so would be very awkward, and I would rather not support it in Debian anyway. What do you think ? I reported the bug upstream. The upstream bug is at https://github.com/neunhoef/io/issues/15 and is marked as closed. However I do not know whether the fix adresses your concern. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Sun, Jun 29, 2014 at 11:08:34PM +0200, Bill Allombert wrote: On Sat, Feb 08, 2014 at 07:57:29PM +0100, Jerome BENOIT wrote: But /usr/share/gap/pkg/GAP PKG/bin - ../../../../lib/gap/pkg/GAP PKG/bin /usr/lib/gap/pkg/GAP PKG/bin/multiarch triplet - ../../../multiarch triplet/gap/pkg/GAP PGK sounds a good compromise. To start with GAP itself, I plan to add a symlink in GAP 4r7p5, /usr/lib/gap/bin/$(GAParch) - /usr/lib/$(multiarch triplet)/gap/bin and make sure packages like IO can be compiled without patching the configure system. Unfortunately some packages like Browse currently expect a file sysinfo.gap-CONFIG, so I will probably add it to GAP 4r7p8. CONFIG is normaly either default64 or default32, but this does not seem suitable for Debian, so maybe I will pick something else. Maybe 'debian'. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Wed, Oct 22, 2014 at 05:00:15AM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Given that we can grab the BUILD GAP architecture as follows, in d/rules: Hello Jérome, CGAP = /usr/bin/gap DEB_BUILD_GAP_INFO_ARCH ?= $(shell echo 'Print(GAPInfo.Architecture);' | $(CGAP) -A -q -T) (I would suggest rather to read the file /usr/lib/gap/sysinfo.gap instead of launching GAP.) I have a naive question: is there a simple way to get the HOST (not the BUILD) GAP architecture ? I am unsure why you call GAPInfo.Architecture the BUILD GAP architecture. According to dpkg-architecture(1): build machine The machine the package is built on. host machine The machine the package is built for. GAPInfo.Architecture is set at compile time to the architecture the package is built for. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Given that we can grab the BUILD GAP architecture as follows, in d/rules: CGAP = /usr/bin/gap DEB_BUILD_GAP_INFO_ARCH ?= $(shell echo 'Print(GAPInfo.Architecture);' | $(CGAP) -A -q -T) I have a naive question: is there a simple way to get the HOST (not the BUILD) GAP architecture ? I am asking because apparently there are a DEB_BUILD_MULTIARCH and a DEB_HOST_MULTIARCH (dpkg-architecture(1)) Thanks in advance, Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJURx2yAAoJEIC/w4IMSybjsjYIALdYjhyqND/bq/JKIEIkPL/0 fKm+mWKoxY1IDKJpZ3O2jB3ERxCDk24qRgSmpA58tmgPLSdX+MWIBjYaRIqhfyz1 0QocWWQUit99D4p0CE5YtufSyCDqRJN5MbPCKxDX+RdOwiYBO2/e6VRp2A5Cguwk Ad5CV5BNQd8SDZ0PfFSOtp/j+Z2Ni9XB0s++be8XCPhMdjvZIBMySbrqG1gNa5Lq rDtkiuvE6WkDpn4Pnb4z0PWpALzrmdIFyCtDeBKdqxH8ATBLY256HZ0mXCYsSqyW XK642qE/CrWPDD2ue9hmbWIilvoJGNmZeEMKJnj2JbP8E5VxtyF4Zv1sz3BxmlE= =f9A1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Fri, Jul 04, 2014 at 11:44:26PM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, On 29/06/14 23:08, Bill Allombert wrote: To start with GAP itself, I plan to add a symlink in GAP 4r7p5, /usr/lib/gap/bin/$(GAParch) - /usr/lib/$(multiarch triplet)/gap/bin and make sure packages like IO can be compiled without patching the configure system. I am on my way to update the GAP IO Debian package: the assertion ``IO can be compiled without patching the configure system'' is nearly true with `4r7p5-1' as AC_FIND_GAP failed at the very end: AC_FIND_GAP can not locate GAP's gmp.h and emit the message ``checking for GAP's gmp.h location... not found, GAP was compiled without GMP''. Can this easy to fix issue be fixed soon ? I do not understand: Just do ./configure_like_gap /usr/lib/gap make and everything should work. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, thanks for your prompt reply. On 05/07/14 10:26, Bill Allombert wrote: On Fri, Jul 04, 2014 at 11:44:26PM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, On 29/06/14 23:08, Bill Allombert wrote: To start with GAP itself, I plan to add a symlink in GAP 4r7p5, /usr/lib/gap/bin/$(GAParch) - /usr/lib/$(multiarch triplet)/gap/bin and make sure packages like IO can be compiled without patching the configure system. I am on my way to update the GAP IO Debian package: the assertion ``IO can be compiled without patching the configure system'' is nearly true with `4r7p5-1' as AC_FIND_GAP failed at the very end: AC_FIND_GAP can not locate GAP's gmp.h and emit the message ``checking for GAP's gmp.h location... not found, GAP was compiled without GMP''. Can this easy to fix issue be fixed soon ? I do not understand: Just do ./configure_like_gap /usr/lib/gap make and everything should work. `./configure_like_gap' is specific to the GAP-IO package, for other GAP package only the classical configure may be available. The macro generally involved to set up is AC_FIND_GAP defined in `IO/m4/ac_find_gap.m4'. This macro determines (weakly: line 150 to 156) whether GAP was built with GMP support. Back to GAP-IO: cd IO ./configure --with-gaproot=/usr/lib/gap gives, as concerned GAP: checking for GAP root directory... /usr/lib/gap checking for GAP architecture... x86_64-pc-linux-gnu-gcc-default64 checking for GAP include files... /usr/lib/gap/src/compiled.h checking for GAP config.h... /usr/lib/gap/bin/x86_64-pc-linux-gnu-gcc-default64/config.h checking for GAP's gmp.h location... not found, GAP was compiled without GMP The GAP's gmp.h is not located because AC_FIND_GAP looks for for it as `/usr/lib/gap/bin/x86_64-pc-linux-gnu-gcc-default64/extern/gmp/include/gmp.h', which effectively does not exist. I guess that the folder `/usr/lib/gap/bin/GAP triplet/extern/' must be created, then the sub-folders `gmp/include', and then the link 'gmp.h' - /usr/include/Debiean triplet/gmp.h must be set up. I am agree that this issue may be not relevant for the GAP IO package itself, but it may be for other GAP packages (e.g., float). The non location of the GMP header introduces some inconsistencies in the building process, as such it may be fixed. Best wishes, Jerome Cheers, Bill. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTt8RHAAoJEIC/w4IMSybjDVoH/3t03F11gB3WAx7YSK6epGc5 1znkGZWc3juRoseahOJzTtsHlIPmoffR43f4cddANwI3wS0ZutJ6PltO6K+T/EpJ SUHXpiycots8agqYTmkPalZmnhWygJCaLWe5QV1cV9cOOOwToL70MmW5EduTuhAC PC8UUtdJO/d+TvKZGA8yWOgURfJYOfw4PtHdkiDC/+yW99npbAF9dFoF3pvKKz0Z z5u/svCgfKq0rW3IEbTBRxzaxfpMP9XIPxMnjb4V2RBgV12bwFRDg/ViNrwlFqGx Q5kdLA9AE4DP2p7qHiFe7ZtMhVmo8HNJb434aN8MsgUCWRGvn0THQJDhvy1WcFo= =N39f -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Sat, Jul 05, 2014 at 11:24:37AM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, thanks for your prompt reply. gives, as concerned GAP: checking for GAP root directory... /usr/lib/gap checking for GAP architecture... x86_64-pc-linux-gnu-gcc-default64 checking for GAP include files... /usr/lib/gap/src/compiled.h checking for GAP config.h... /usr/lib/gap/bin/x86_64-pc-linux-gnu-gcc-default64/config.h checking for GAP's gmp.h location... not found, GAP was compiled without GMP I am agree that this issue may be not relevant for the GAP IO package itself, but it may be for other GAP packages (e.g., float). The non location of the GMP header introduces some inconsistencies in the building process, as such it may be fixed. GAP does not provide a file gmp.h. Instead, this file is part of libgmp-dev. GAP is configured in with --with-gmp=system which is a supported configuration. AC_FIND_GAP is not shipped with GAP so it is a bug in IO. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, On 05/07/14 12:29, Bill Allombert wrote: On Sat, Jul 05, 2014 at 11:24:37AM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, thanks for your prompt reply. gives, as concerned GAP: checking for GAP root directory... /usr/lib/gap checking for GAP architecture... x86_64-pc-linux-gnu-gcc-default64 checking for GAP include files... /usr/lib/gap/src/compiled.h checking for GAP config.h... /usr/lib/gap/bin/x86_64-pc-linux-gnu-gcc-default64/config.h checking for GAP's gmp.h location... not found, GAP was compiled without GMP I am agree that this issue may be not relevant for the GAP IO package itself, but it may be for other GAP packages (e.g., float). The non location of the GMP header introduces some inconsistencies in the building process, as such it may be fixed. GAP does not provide a file gmp.h. Instead, this file is part of libgmp-dev. GAP is configured in with --with-gmp=system which is a supported configuration. I am agree. AC_FIND_GAP is not shipped with GAP so it is a bug in IO. AC_FIND_GAP is used by some GAP package, so the issue does not concern only GAP-IO. Even if I am agree to say that the implemented location of gmp.h is weak, it seems nevertheless that an external include hierarchy is expected in `/usr/lib/gap/bin/GAP triplet/extern'. If this assertion is true, then the --with-gmp=system in GAP does not complete its jobs properly, so it might be a bug in the GAP source itself --- after all, it is GAP itself that may point the GMP material with which it was built. What do you think ? Best wishes, Jerome Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTt9dUAAoJEIC/w4IMSybjHJ8H/10Zyi919hBwc91wiF7TT9CS /arvIkd10Uiz8O3GKFQLZdR8zntWvnIg7I4V5QFQ4nzNrZgb7NFS8NhBZP0t4oKI 0ymuum5B+hQnx2OdaCU078m6TqS8+W4uA71rJxKDv90/JIPzi71aSAYB+RvuVSia oj9ZpZ0NXBD4VauVrmaVYY5LYaQbxSGxidBrl85g0xcTnLuzGi6SIS5Bmu9CbHaP rZOidVjXc96cSM5Ykl0JjMEFz9lhecif2LGIJKLuCTBcXUwKOmZqEyf3feaG/XAo FxLMYAEzqa3UamaKQ0aSa0P+OQMMbm3mG32Jh2X26QUXxMTRdxU7ir/KRSD4KCQ= =VwTb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Sat, Jul 05, 2014 at 12:45:51PM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, On 05/07/14 12:29, Bill Allombert wrote: On Sat, Jul 05, 2014 at 11:24:37AM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, thanks for your prompt reply. gives, as concerned GAP: checking for GAP root directory... /usr/lib/gap checking for GAP architecture... x86_64-pc-linux-gnu-gcc-default64 checking for GAP include files... /usr/lib/gap/src/compiled.h checking for GAP config.h... /usr/lib/gap/bin/x86_64-pc-linux-gnu-gcc-default64/config.h checking for GAP's gmp.h location... not found, GAP was compiled without GMP I am agree that this issue may be not relevant for the GAP IO package itself, but it may be for other GAP packages (e.g., float). The non location of the GMP header introduces some inconsistencies in the building process, as such it may be fixed. GAP does not provide a file gmp.h. Instead, this file is part of libgmp-dev. GAP is configured in with --with-gmp=system which is a supported configuration. I am agree. AC_FIND_GAP is not shipped with GAP so it is a bug in IO. AC_FIND_GAP is used by some GAP package, so the issue does not concern only GAP-IO. Even if I am agree to say that the implemented location of gmp.h is weak, it seems nevertheless that an external include hierarchy is expected in `/usr/lib/gap/bin/GAP triplet/extern'. If this assertion is true, then the --with-gmp=system in GAP does not complete its jobs properly, so it might be a bug in the GAP source itself --- after all, it is GAP itself that may point the GMP material with which it was built. I do not see how gap can generate the extern hierarchy when using --with-gmp=system and doing so would be very awkward, and I would rather not support it in Debian anyway. What do you think ? I reported the bug upstream. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Again, On 05/07/14 13:43, Bill Allombert wrote: On Sat, Jul 05, 2014 at 12:45:51PM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, On 05/07/14 12:29, Bill Allombert wrote: On Sat, Jul 05, 2014 at 11:24:37AM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, thanks for your prompt reply. gives, as concerned GAP: checking for GAP root directory... /usr/lib/gap checking for GAP architecture... x86_64-pc-linux-gnu-gcc-default64 checking for GAP include files... /usr/lib/gap/src/compiled.h checking for GAP config.h... /usr/lib/gap/bin/x86_64-pc-linux-gnu-gcc-default64/config.h checking for GAP's gmp.h location... not found, GAP was compiled without GMP I am agree that this issue may be not relevant for the GAP IO package itself, but it may be for other GAP packages (e.g., float). The non location of the GMP header introduces some inconsistencies in the building process, as such it may be fixed. GAP does not provide a file gmp.h. Instead, this file is part of libgmp-dev. GAP is configured in with --with-gmp=system which is a supported configuration. I am agree. AC_FIND_GAP is not shipped with GAP so it is a bug in IO. AC_FIND_GAP is used by some GAP package, so the issue does not concern only GAP-IO. Even if I am agree to say that the implemented location of gmp.h is weak, it seems nevertheless that an external include hierarchy is expected in `/usr/lib/gap/bin/GAP triplet/extern'. If this assertion is true, then the --with-gmp=system in GAP does not complete its jobs properly, so it might be a bug in the GAP source itself --- after all, it is GAP itself that may point the GMP material with which it was built. I do not see how gap can generate the extern hierarchy when using --with-gmp=system and doing so would be very awkward, and I would rather not support it in Debian anyway. What do you think ? I reported the bug upstream. Recorded. So I will step forward by adapting the locating machinery. Best wishes, Jerome Cheers, Bill. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTuAZzAAoJEIC/w4IMSybjb6kH/2TlS+pNJm2ZPX9t/dPmZdNc U00MwY4EwwvM0BaR020S/KxYk3UDSZQRDLDnLKyNLSCn0ste6/5ByjFdD4uCZBhR Q9DAyey/1sRwRD+A1EJuLO634qAG8U/llt3jyDmB6MC20hgVd7U9TxE4L3cfdBGF IBhxCDtIhXeRmzWz9xbNihngP0aeT+5CcsYz5F/mCRSRjZDkUL6xmeIxxlccPdio QEHuqcBpK9cz2wV+VrgGBlrFLkrJ5tKB/JEy6eCowEhoVk4DPfoyMjNSfblJYX25 wn/8l+2o812ARh+co+ZWBFYVHTrSd6C53T8lj2f29TBxL++gHLblTBxF/fmIQH4= =9T64 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, On 29/06/14 23:08, Bill Allombert wrote: To start with GAP itself, I plan to add a symlink in GAP 4r7p5, /usr/lib/gap/bin/$(GAParch) - /usr/lib/$(multiarch triplet)/gap/bin and make sure packages like IO can be compiled without patching the configure system. I am on my way to update the GAP IO Debian package: the assertion ``IO can be compiled without patching the configure system'' is nearly true with `4r7p5-1' as AC_FIND_GAP failed at the very end: AC_FIND_GAP can not locate GAP's gmp.h and emit the message ``checking for GAP's gmp.h location... not found, GAP was compiled without GMP''. Can this easy to fix issue be fixed soon ? Best wishes, Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTtyAvAAoJEIC/w4IMSybj5I8H/RMSloNSiQm2TkSni+sZNaQw 3dnlz6wJTYVg63spzVv0JaX+wBnK/KATVsM0SIi8+XILbjYa1MPcm+N7WcpaCHKD +BESputM5lZdTgfQFxD3ahzyekpzC9fgZwGiAtS1lvxwBhzyHN+aYaoiU+cUXTTh ghw9c332QRTLtcIMDekNu/H8rh9PXRRiPUFwiu+1vM99klvqACZQkGy2t12vEhh5 O/77B73ddITwgdfy1VcTBXChmoHdrHl/LRAgHXOXPxW6IjN+h+hRk6hUHSUS2HnC p+59O4B1lcOmmasloJGZMuwIC0kPcacZduXfjMcYgxjq/7t4vsfedoH0FDAqLDw= =7vsY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, On 29/06/14 23:08, Bill Allombert wrote: On Sat, Feb 08, 2014 at 07:57:29PM +0100, Jerome BENOIT wrote: But /usr/share/gap/pkg/GAP PKG/bin - ../../../../lib/gap/pkg/GAP PKG/bin /usr/lib/gap/pkg/GAP PKG/bin/multiarch triplet - ../../../multiarch triplet/gap/pkg/GAP PGK sounds a good compromise. To start with GAP itself, I plan to add a symlink in GAP 4r7p5, When do you plan to bring GAP 4r7p5 to Debian ? /usr/lib/gap/bin/$(GAParch) - /usr/lib/$(multiarch triplet)/gap/bin and make sure packages like IO can be compiled without patching the configure system. Note however, that true multiarch would require splitting all arch:any GAP packages in two packages, which is more costly than any potential benefit of multiarch GAP packages. Anyway, the object files in /usr/lib/gap/bin/ should be multiarch as well - --- understood that the best is for GAP to support a true API library first. Best wishes, Jerome Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTsQP3AAoJEIC/w4IMSybjHhkH+wZdUBSxlfrSTK+FjKWWISSR iPQ9f41Ru8JyqowmKmX4bwAibCEb/BCE9Sd1BcgcPQZNFGbRLY8xLtUiwtPrHJ9R phrgGHJTIJlf37DJgqMPVcv4Q1jW5ifZ0lJ7SOPBfBDlUYwFp8BwJfRrsZ+CiLhV vtVc6wMwOPjBWSXBTX1Ej48LodxikUZE0ch1fwy30jLh77F2cV0csuGt4rgnp9wf QtlxIkC0N5qpKtNQK2KKBNbOWH9gdQMi9PC2+s6woRQD8ogF8/xUb6CKufYyAvEP 7RMj7sMrTmaRM3o8nJ32O0D7bqUBySwCMak3y2qzyspJk6040KMoBUXUmG62CCo= =Q6mL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Mon, Jun 30, 2014 at 08:30:29AM +0200, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Bill, On 29/06/14 23:08, Bill Allombert wrote: On Sat, Feb 08, 2014 at 07:57:29PM +0100, Jerome BENOIT wrote: But /usr/share/gap/pkg/GAP PKG/bin - ../../../../lib/gap/pkg/GAP PKG/bin /usr/lib/gap/pkg/GAP PKG/bin/multiarch triplet - ../../../multiarch triplet/gap/pkg/GAP PGK sounds a good compromise. To start with GAP itself, I plan to add a symlink in GAP 4r7p5, /usr/lib/gap/bin/$(GAParch) - /usr/lib/$(multiarch triplet)/gap/bin When do you plan to bring GAP 4r7p5 to Debian ? As soon as I have finalised the binary interface, i.e. the value of GAParch. Probably in two days. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Sat, Feb 08, 2014 at 07:57:29PM +0100, Jerome BENOIT wrote: But /usr/share/gap/pkg/GAP PKG/bin - ../../../../lib/gap/pkg/GAP PKG/bin /usr/lib/gap/pkg/GAP PKG/bin/multiarch triplet - ../../../multiarch triplet/gap/pkg/GAP PGK sounds a good compromise. To start with GAP itself, I plan to add a symlink in GAP 4r7p5, /usr/lib/gap/bin/$(GAParch) - /usr/lib/$(multiarch triplet)/gap/bin and make sure packages like IO can be compiled without patching the configure system. Note however, that true multiarch would require splitting all arch:any GAP packages in two packages, which is more costly than any potential benefit of multiarch GAP packages. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Sat, Feb 08, 2014 at 06:31:08AM +0100, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Again: This is too fragile to be used by Debian. I am working with upstream to improve this (in particular: not include the compiler name in the ABI). In the mean time, my plan is to use /usr/share/gap/pkg/name/bin instead. This can be a symlink to /usr/lib/multiarch triplet/gap/pkg/name/bin. I guess that you meant In the mean time, my plan is to use /usr/share/gap/pkg/name/bin/multiarch triplet instead. I do not intent to support this path. Adding multi-arch path in /usr/share seems wrong. And can you make it effective by releasing new Debian package (at least for GAP 4r6) ? As I said, I have some hardware issue, so I cannot upload anything. Maybe next week... Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Fri, Feb 07, 2014 at 07:54:37AM +0100, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am working with upstream to improve this (in particular: not include the compiler name in the ABI). In the mean time, my plan is to use /usr/share/gap/pkg/name/bin instead. This can be a symlink to /usr/lib/multiarch triplet/gap/pkg/name/bin. Can you also ask them to gather the object files into a library ? As I said, the .o are not a library: they do not provides a library-like ABI/API. Instead they are meant to relink the new gap interpretor with extra functions, like gac does. On Debian, this is mostly deprecated by the use of dlopen inside the standard gap binary. There are people working on providing a proper library, but this is done outside this package. And it will stay this way at least until a proper ABI is defined. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 08/02/14 16:42, Bill Allombert wrote: On Sat, Feb 08, 2014 at 06:31:08AM +0100, Jerome BENOIT wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Again: This is too fragile to be used by Debian. I am working with upstream to improve this (in particular: not include the compiler name in the ABI). In the mean time, my plan is to use /usr/share/gap/pkg/name/bin instead. This can be a symlink to /usr/lib/multiarch triplet/gap/pkg/name/bin. I guess that you meant In the mean time, my plan is to use /usr/share/gap/pkg/name/bin/multiarch triplet instead. I do not intent to support this path. Adding multi-arch path in /usr/share seems wrong. I am agree. A proper alternative would be /usr/lib/gap/pkg/name/bin/multiarch triplet And can you make it effective by releasing new Debian package (at least for GAP 4r6) ? As I said, I have some hardware issue, so I cannot upload anything. Maybe next week... Ok. Cheers, Bill. Best wishes, Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJS9lz9AAoJEIC/w4IMSybj7JEIAMm9SfgQWfJXM3qvkSE6L7HG r3JKo8IYMhHb/FbGs+EeDQfLcOKXZHYbTS6q6t1U4fWo9yXhI9+rmwjKVDpuuqyS DhtIr544bQ+zCb8R0fzvTGkCftspQmjQfGq11uC03TYKG9iJv0B0T8OP8IWlWaNl /KhsIJiQQZCcM+3mmg2yZV35xwujohikwqK0f+eZqrydAgdPAqfpQlHPQNwbVZ9P Jq0g54ZyIFwUxVlJMcZpRSNzGJObpXxhnr/ySUjgx63T5tt8rXD9G8SLqTs0ECKC rvNK83Qebm1ESm6/T4agPF96CshsMQmg/IjFE0bm1z8cTbrg2lvQ0KBdrxsM+Go= =hnRX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Wed, Jan 29, 2014 at 05:34:47PM +0100, Bill Allombert wrote: On Thu, Jan 23, 2014 at 09:46:45AM +0100, Jerome Benoit wrote: Package: gap-dev Version: 4r6p5-3.1 Severity: wishlist Dear Maintainer, please provide multiarch support for gap-dev: the distributed object files in /usr/lib/gap/bin/ should be placed into an architecture dependent subfolder as /usr/lib/gap/bin/multiarch name/ , while the GAP environment variable GAPInfo.Architecture should be set up arccordingly (for this example, to multiarch name). This will bring multiarch support to GAP Hello Jérome, Multiarch is only intended to cover shared library. There is currently no support in Debian for multiarch executables. GAP does not provide any shared libraries, but an executable, so is outside the scope of multiarch, and I do not think it is worth the effort to have multiarch support for GAP at this stage. The .o files are only meant to be used by the GAC compiler. If we move toward using multiarch path (irrespectively of actual multiarch support), then we should use /usr/lib/multiarch triplet/gap and not a GAP specific path. and it will also satisfy some GAP expectation as expressed in the ac_find_gap.m4 used by some GAP packages with binary modules. I do not intent to support such expectation. The value of GAParch is something like x86_64-pc-linux-gnu-x86_64-linux-gnu-gcc-default64 and change each time the compiler name change. This is too fragile to be used by Debian. I am working with upstream to improve this (in particular: not include the compiler name in the ABI). In the mean time, my plan is to use /usr/share/gap/pkg/name/bin instead. This can be a symlink to /usr/lib/multiarch triplet/gap/pkg/name/bin. I realized creating a symlink from /usr/share/... to /usr/lib/multiarch triplet/... is a bad suggestion since this make /usr/share/... architecture dependent. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I realized creating a symlink from /usr/share/... to /usr/lib/multiarch triplet/... is a bad suggestion since this make /usr/share/... architecture dependent. But /usr/share/gap/pkg/GAP PKG/bin - ../../../../lib/gap/pkg/GAP PKG/bin /usr/lib/gap/pkg/GAP PKG/bin/multiarch triplet - ../../../multiarch triplet/gap/pkg/GAP PGK sounds a good compromise. Cheers, Bill. Best wishes,'Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJS9n4NAAoJEIC/w4IMSybjoigH/20cvBJhaBCzYkgc4kOmUKHg Q2QKX4prz/quOhtAGJIyvLLSw7liHm5nWr+GgWNeiF2lpIuEymuEepspKMwIOlAa 2QTsXz/Lqs7gSNO+kaL10dmFR0ndqEtfZEYuV9w1MU/aOzwW2IDUiSMXhYXanFLr BXL2sQgmRr/rEI/ljf+EIro4sXSmWOUzqBAX08asW+zW2WgWz0/f6TTQjwYii0yc vfkM2mYW04nNdnWClbgOzZ97yjHG15Ea3GZvQq19tJesZBAr4GKRm/E4rEnBlyRx o5GPlo2kYyAAKCFS7zh7o9JZjC+Uwr4WLPE6XNIt26ewnUglmP7RcfFez7pJ1L8= =rjzQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Again: This is too fragile to be used by Debian. I am working with upstream to improve this (in particular: not include the compiler name in the ABI). In the mean time, my plan is to use /usr/share/gap/pkg/name/bin instead. This can be a symlink to /usr/lib/multiarch triplet/gap/pkg/name/bin. I guess that you meant In the mean time, my plan is to use /usr/share/gap/pkg/name/bin/multiarch triplet instead. Can you confirm that ? And can you make it effective by releasing new Debian package (at least for GAP 4r6) ? I guess that only /usr/lib/gap/sysinfo.gap has to be updated by replacing the GAP long tuple by the multiarch triple. Best wishes, Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJS9cD9AAoJEIC/w4IMSybjjZsH/1MnbJeNndqgJWFkbGUzQXdj CQpe8R9qQiJYqyf5m/KCIrvJMHm/5NwxOTai379W5Hf4AxSrrRcDF485RGprSMb9 1XdE+KkA5mvpUE97GirMYrjtzaq73zzyZbBZCXxQnf9ljs9rMGUn/lx6nPZOCQnI J5vm695X+yrcV92ilc6KSrzeZKwH0mQq9sSyCk7321uvU8vk9OL1eKj+a4QI7O9O +IPNAudIZ7jtmEScYxndDnfN87QSdcZ9pp2vJwdrctFFo49rOamWJLxsDrEAfjl8 xM57rphrSL0x0fm+kAxSZaLNmhpBRt4t4hFb8KUafKO3206VP/ceitU6lbZIFtM= =v3s4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 29/01/14 17:34, Bill Allombert wrote: On Thu, Jan 23, 2014 at 09:46:45AM +0100, Jerome Benoit wrote: Package: gap-dev Version: 4r6p5-3.1 Severity: wishlist Dear Maintainer, please provide multiarch support for gap-dev: the distributed object files in /usr/lib/gap/bin/ should be placed into an architecture dependent subfolder as /usr/lib/gap/bin/multiarch name/ , while the GAP environment variable GAPInfo.Architecture should be set up arccordingly (for this example, to multiarch name). This will bring multiarch support to GAP Hello J￩rome, Multiarch is only intended to cover shared library. Strictly speaking or sticking to the definition, this is correct. There is currently no support in Debian for multiarch executables. GAP does not provide any shared libraries, but an executable, so is outside the scope of multiarch, and I do not think it is worth the effort to have multiarch support for GAP at this stage. The .o files are only meant to be used by the GAC compiler. But the .o files are architecture dependent, so a multiarch support make sense: as a library is before all a rationalized archive of object, these .o may be gathered into an archive: this will render this part of GAP more contemporary, and this will allow a clean multiarch support. If we move toward using multiarch path (irrespectively of actual multiarch support), then we should use /usr/lib/multiarch triplet/gap and not a GAP specific path. I am agree. But the GAP specific setup, /usr/lib/gap/pkg/GAP Package/bin/GAP tuple/GAP Package.so for the GAP Package binary module (if any), does not fit well with Debian customs. A possibility will be to ply with links, as it is currently done for documentation, to full fill both Debian policy and GAP expectation. The GAP tuple is set up in the /usr/lib/gap/sysinfo.gap : I guess that a good idea would be to replace the GAP trplet by the Debian triplet. So let assume that the GAP tuple is replaced by the Debian triplet. Then, wrt the current documentation scheme (for example gapdoc), we can set up the following: /usr/lib/Debain multiarch triple/gap/GAP Package - /usr/lib/gap/pkg/GAP Package/bin/GAP/Debian multiarch triple This favours GAP scheme, the alternative that favours Debain instead can be chosen too: /usr/lib/gap/pkg/GAP Package/bin/GAP/Debian multiarch triple - /usr/lib/Debain multiarch triple/gap/GAP Package and it will also satisfy some GAP expectation as expressed in the ac_find_gap.m4 used by some GAP packages with binary modules. I do not intent to support such expectation. The value of GAParch is something like x86_64-pc-linux-gnu-x86_64-linux-gnu-gcc-default64 and change each time the compiler name change. This is too fragile to be used by Debian. Agree. I am working with upstream to improve this (in particular: not include the compiler name in the ABI). In the mean time, my plan is to use /usr/share/gap/pkg/name/bin instead. This can be a symlink to /usr/lib/multiarch triplet/gap/pkg/name/bin. Can you also ask them to gather the object files into a library ? Note that the configure header /usr/include/gap/config.h (current Debian package location) is architecture dependent as well: ac_find_gap.m4 expects to find it in /usr/lib/gap/bin/GAPInfo.Architecture/. Yes, I know. There is a trade-off between keeping file where upstream expect them and put them where Debian expect them. Upstream do not provide a 'make install' target as a guidance. A good idea would be to ask to the upstream team to provide an autotools machinery that is respect better Linux customs: the GAP autotools set ups mainly cast autotools to GAP, it should be the reverse; GAP should provide an autotools machinery that follows Linux custom. This is rather a choice because the effort to do so is not that huge. If the current location prove to be too much an issue, I am willing to reconsider it, or add work-arounds. (I guess that the current gap-dev package must be split.) The multiarch specification for header files are not fully specified yet, but I do not think splitting the package is necessary (However some headers would need to be moved to /usr/include/multiarch triplet/). If the set of objects files is considered as a pre-library, the package must be split: grossly, one containing the headers, the second the library (and the config.h headers). Cheers, Bill. Best wishes, Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJS9IMeAAoJEIC/w4IMSybjgGoH/03FIV2M/LErLoVkW29anjBo iuNTUcgaOXUfE45rksvTzto6EVW2g13ExDvsx0td3AFJaO95IkqiUkHFP8yrc5Z1 JozDZ4B/dx+IyWM+zWcu8Motw26x0hGT7ON8QskEetuJ6mL0OUzUCbv5AYBLfEh0 /b7D7tNM3X9S+9gKw0DVH/KDLPa87eu+SEBn4Uch3dWt6K+zlSRkOLnuNZ54Igaz uqwVN+T5q6xNJHwhZx/ny8yT7uefZdg6fYjazh2evfE59+YDr2AwK2qg2CB2y2b+
Bug#736398: gap-dev: multi-architecture support
On Thu, Jan 23, 2014 at 09:46:45AM +0100, Jerome Benoit wrote: Package: gap-dev Version: 4r6p5-3.1 Severity: wishlist Dear Maintainer, please provide multiarch support for gap-dev: the distributed object files in /usr/lib/gap/bin/ should be placed into an architecture dependent subfolder as /usr/lib/gap/bin/multiarch name/ , while the GAP environment variable GAPInfo.Architecture should be set up arccordingly (for this example, to multiarch name). This will bring multiarch support to GAP Hello Jérome, Multiarch is only intended to cover shared library. There is currently no support in Debian for multiarch executables. GAP does not provide any shared libraries, but an executable, so is outside the scope of multiarch, and I do not think it is worth the effort to have multiarch support for GAP at this stage. The .o files are only meant to be used by the GAC compiler. If we move toward using multiarch path (irrespectively of actual multiarch support), then we should use /usr/lib/multiarch triplet/gap and not a GAP specific path. and it will also satisfy some GAP expectation as expressed in the ac_find_gap.m4 used by some GAP packages with binary modules. I do not intent to support such expectation. The value of GAParch is something like x86_64-pc-linux-gnu-x86_64-linux-gnu-gcc-default64 and change each time the compiler name change. This is too fragile to be used by Debian. I am working with upstream to improve this (in particular: not include the compiler name in the ABI). In the mean time, my plan is to use /usr/share/gap/pkg/name/bin instead. This can be a symlink to /usr/lib/multiarch triplet/gap/pkg/name/bin. Note that the configure header /usr/include/gap/config.h (current Debian package location) is architecture dependent as well: ac_find_gap.m4 expects to find it in /usr/lib/gap/bin/GAPInfo.Architecture/. Yes, I know. There is a trade-off between keeping file where upstream expect them and put them where Debian expect them. Upstream do not provide a 'make install' target as a guidance. If the current location prove to be too much an issue, I am willing to reconsider it, or add work-arounds. (I guess that the current gap-dev package must be split.) The multiarch specification for header files are not fully specified yet, but I do not think splitting the package is necessary (However some headers would need to be moved to /usr/include/multiarch triplet/). Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
Package: gap-dev Version: 4r6p5-3.1 Severity: wishlist Dear Maintainer, please provide multiarch support for gap-dev: the distributed object files in /usr/lib/gap/bin/ should be placed into an architecture dependent subfolder as /usr/lib/gap/bin/multiarch name/ , while the GAP environment variable GAPInfo.Architecture should be set up arccordingly (for this example, to multiarch name). This will bring multiarch support to GAP and it will also satisfy some GAP expectation as expressed in the ac_find_gap.m4 used by some GAP packages with binary modules. Note that the configure header /usr/include/gap/config.h (current Debian package location) is architecture dependent as well: ac_find_gap.m4 expects to find it in /usr/lib/gap/bin/GAPInfo.Architecture/. (I guess that the current gap-dev package must be split.) Best regards, Jerome BENOIT -- System Information: Debian Release: Wheezy* APT prefers wheezy APT policy: (990, 'wheezy'), (990, 'stable-updates'), (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12.6-amd64-mbp62 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gap-dev depends on: ii gap-core 4r6p5-3.1 ii gcc 4:4.7.2-1 gap-dev recommends no packages. gap-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
