Re: scotch: packaging a version with 64bit integers
On 11.01.2018 09:25, Dominik 'Rathann' Mierzejewski wrote: Hi, Sandro. On Wednesday, 10 January 2018 at 14:58, Sandro Mani wrote: I've received a request to package a version of scotch with 64bit integers (as opposed to 32bit). I suppose the details are less important, the bottom line is scotch 32bit: typedef int32_t SCOTCH_Num; scotch 64bit: typedef int64_t SCOTCH_Num; where SCOTCH_Num affects the public ABI and is used by third parties which use scotch. Upstream allows selecting the integer size at compile-time (i.e. passing -DINTSIZE64 for int64_t). However, this choice has no effect on the library name, so vanilla upstream will build a library named libscotch.so regardless of how you configure it. Why don't you talk to upstream about this. Having the two builds parallel-installable would be a benefit for everyone. Please take a look at what we did in openblas and arpack (https://github.com/opencollab/arpack-ng/issues/30) Hopefully that will convince upstream to support library name suffixing. Indeed also adding a _64 suffix to the API methods is a good point, yeah I'll try raising the issue upstream. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: scotch: packaging a version with 64bit integers
Hi, Sandro. On Wednesday, 10 January 2018 at 14:58, Sandro Mani wrote: > I've received a request to package a version of scotch with 64bit integers > (as opposed to 32bit). I suppose the details are less important, the bottom > line is > > scotch 32bit: typedef int32_t SCOTCH_Num; > > scotch 64bit: typedef int64_t SCOTCH_Num; > > where SCOTCH_Num affects the public ABI and is used by third parties which > use scotch. > > > Upstream allows selecting the integer size at compile-time (i.e. passing > -DINTSIZE64 for int64_t). However, this choice has no effect on the library > name, so vanilla upstream will build a library named libscotch.so regardless > of how you configure it. Why don't you talk to upstream about this. Having the two builds parallel-installable would be a benefit for everyone. Please take a look at what we did in openblas and arpack (https://github.com/opencollab/arpack-ng/issues/30) Hopefully that will convince upstream to support library name suffixing. > I'm skeptical whether introducing a downstream scotch64 package with i.e. > libscotch64.so is a good solution, given that possibly no build system of > third-party software using scotch knows about libscotch64.so and would need > to be carefully patched (i.e. to not mix parts using libscotch and those > using libscotch64). Also, introducing downstream specific suffixes is never > a good idea. In general yes, but in this domain it's a common trend (openblas and arpack are doing it already). > The alternative would be to just switch the main scotch package to 64bit > integers, but this may be undesirable for memory-bound applications which > rely on the smaller memory-usage of 32bit integers. Type incompatibility (narrowing) could also be an issue. > I'm not really sure whether there is a good solution, happy to hear > opinions. I'd open a discussion with upstream to see where it goes. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: scotch: packaging a version with 64bit integers
Sorry for the top post, on my phone... Telling third party software to link against a different soname suffixed with 64 would be pkg-config's job, usually. Dridi On Jan 10, 2018 14:59, "Sandro Mani" wrote: Hi I've received a request to package a version of scotch with 64bit integers (as opposed to 32bit). I suppose the details are less important, the bottom line is scotch 32bit: typedef int32_t SCOTCH_Num; scotch 64bit: typedef int64_t SCOTCH_Num; where SCOTCH_Num affects the public ABI and is used by third parties which use scotch. Upstream allows selecting the integer size at compile-time (i.e. passing -DINTSIZE64 for int64_t). However, this choice has no effect on the library name, so vanilla upstream will build a library named libscotch.so regardless of how you configure it. I'm skeptical whether introducing a downstream scotch64 package with i.e. libscotch64.so is a good solution, given that possibly no build system of third-party software using scotch knows about libscotch64.so and would need to be carefully patched (i.e. to not mix parts using libscotch and those using libscotch64). Also, introducing downstream specific suffixes is never a good idea. The alternative would be to just switch the main scotch package to 64bit integers, but this may be undesirable for memory-bound applications which rely on the smaller memory-usage of 32bit integers. I'm not really sure whether there is a good solution, happy to hear opinions. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
scotch: packaging a version with 64bit integers
Hi I've received a request to package a version of scotch with 64bit integers (as opposed to 32bit). I suppose the details are less important, the bottom line is scotch 32bit: typedef int32_t SCOTCH_Num; scotch 64bit: typedef int64_t SCOTCH_Num; where SCOTCH_Num affects the public ABI and is used by third parties which use scotch. Upstream allows selecting the integer size at compile-time (i.e. passing -DINTSIZE64 for int64_t). However, this choice has no effect on the library name, so vanilla upstream will build a library named libscotch.so regardless of how you configure it. I'm skeptical whether introducing a downstream scotch64 package with i.e. libscotch64.so is a good solution, given that possibly no build system of third-party software using scotch knows about libscotch64.so and would need to be carefully patched (i.e. to not mix parts using libscotch and those using libscotch64). Also, introducing downstream specific suffixes is never a good idea. The alternative would be to just switch the main scotch package to 64bit integers, but this may be undesirable for memory-bound applications which rely on the smaller memory-usage of 32bit integers. I'm not really sure whether there is a good solution, happy to hear opinions. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
