Re: [Help-gsl] Building GSL
Hi Peter,
Thanks very much for replying.
I think there must be some assumption about where things like autoconf live as
I had this problem when I installed the build tools via nix but not via
homebrew (nix-env -i autoconf vs brew install autoconf).
In the end I managed to get nix to build gsl with this in my shell.nix
> { nixpkgs ? import { overlays = [(self: super: {gsl =
> super.gsl.overrideAttrs (o: {CFLAGS = "-DDEBUG -O3";});})]; }
> , compiler ? "ghc822"
> , doBenchmark ? false }:
A bit simpler than the instructions in HACKING I think - I am leaving it here
in case anyone else is searching for how to build gsl via nix.
Maybe I should create a PR to add this to the HACKING instructions?
Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuch.wordpress.com
Twitter: @idontgetoutmuch
> On 24 Feb 2018, at 04:49, Peter Johansson wrote:
>
> Hello,
>
>
> On 2/24/2018 5:29 AM, Dominic Steinitz wrote:
>
>> Searching the web suggests trying autoreconf -i -v but this gives lots of
>> errors about libtool.
>
> I suggest you read file 'HACKING' and follow the instructions there. It used
> to work for me, but it was a couple of years ago.
>
> hth,
> Peter
Re: [Help-gsl] Building GSL
Hello, On 2/24/2018 5:29 AM, Dominic Steinitz wrote: Searching the web suggests trying autoreconf -i -v but this gives lots of errors about libtool. I suggest you read file 'HACKING' and follow the instructions there. It used to work for me, but it was a couple of years ago. hth, Peter
Re: [Help-gsl] Building gsl-1.15 under MinGW
Thanks Armin, for trying. If CygWin is not int the PATH, there is probably no risk of using its tools instead of the MinGW's ones. Sorry for the noise, it sounded similar to me as one of my previous problems. David On 08/18/2011 04:24 PM, Armin Armbruster wrote: Thanks David, I played around with the PATH variable and took out everything other than the standard windows directories, all to no avail. I also checked which sed and awk are called, they are the ones from MinGW/msys/1.0/bin: $ which sed /bin/sed.exe $ which awk /bin/awk.exe $ sed --version GNU sed version 4.2.1 $ awk --version GNU Awk 3.1.7 I do have a cygwin installation, but the awk and sed are older versions (3.1.6 and 4.1.5, respectively). I'm positive I tried ./configure without cygwin in my PATH. Are there any other tools used (other than awk and sed) by ./configure? Thanks, Armin On 8/18/2011 at 09:11 AM, David Komanek address@hidden wrote: Hi, what are the PATH variables on your systems ? Once I had experienced similar problem with different package using ruby gems and I resolved it by reorganizing PATHs. Some binaries were called from CygWin installation, other ones from MinGW Maybe it is not your case, but check the Windows PATH variable to be sure. David ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
I found a workaround: I installed a virtual machine with WinXP, SP3 and was able to build gsl-1.15 with the same MinGW/Msys installation that didn't work on my regular machine. I compared the config.log files and the only differences I could see where the hostname and some path settings. As I mentioned in previous mails, I played around with the path settings quite a bit, so I'm pretty sure that's not the problem. But then, what else could it be? Anyhow, thanks for everybody who tried to help. If anybody has another idea to try let me know. I can't spend much more time on it, but if it's something quick to try I'm willing to do it. Thanks, Armin ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
Hi, I've experienced similar problem in past and the solution was to put the MinGW directory in the path *before* the standard Windows directories. The reason was that one command already exists in the Windows path but it was not the good one, but I don't remember which one it was. I recommend to always put mingw directories in the path before window's directory because it is better to let the shell find first the unix-like mingw commands instead of the windows' native one. I hope that helps. Francesco ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
Hi, what are the PATH variables on your systems ? Once I had experienced similar problem with different package using ruby gems and I resolved it by reorganizing PATHs. Some binaries were called from CygWin installation, other ones from MinGW Maybe it is not your case, but check the Windows PATH variable to be sure. David On 08/18/2011 06:26 AM, Sisyphus wrote: - Original Message - From: Armin Armbruster aarmb...@ndigital.com To: help-gsl@gnu.org; Sisyphus sisyph...@optusnet.com.au Sent: Thursday, August 18, 2011 4:02 AM Subject: Re: [Help-gsl] Building gsl-1.15 under MinGW Hi Rob, Thanks for your reply. here's gcc -v: $ gcc -v Using built-in specs. COLLECT_GCC=C:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --wi th-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r untime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.2 (GCC) Some more background: - I'm using the latest MinGW (downloaded from http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/), mingw-get-inst-20110802.exe). - $ help ==GNU bash, version 3.1.17(1)-release (i686-pc-msys) - my host OS is MS Windows XP, SP3 - gsl downloaded from ftp://ftp.gnu.org/gnu/gsl/gsl-1.15.tar.gz Last night I've tried to build the same gsl on my computer at home (running Windows 7 Home Premium, SP1, 64 bit OS). I used the same MinGW installer and the same GSL package and make ran without problems. I compared the config.log files in both cases (see attachment config_log_diff.txt). The only significant difference that I can see is that uname -s returns MINGW32_NT-5.1 on the XP machine and MINGW32_NT-6.1 on the Win7 machine. The one thing I noticed is, that the resulting config.h is a direct copy of config.h.in!!! The only difference is the first line added to config.h. That makes me believe that something with awk and/or sed isn't working properly. I don't have a full understanding of the configure script but from what I understand it is taking the config.h.in file as a template and mangles it based on some test results to turn on some of the defines. Is that right? = I don't understand it all that well either, but I believe your understanding is basically correct. In addition to the gcc-3.4.5 that I used yesterday, I also have the very same setup that you have - namely the one installed by mingw-get-inst-20110802.exe. When I use that, a correct config.h is still being created for me I'm fairly sure that your only problem is that your config.h is not being generated correctly ... and I have no idea why that happens. The only differences in our config.log files is the things you would expect to see as the result of having been run on different machines, different pathnames, etc. I can see nothing that explains the reason that your config.h turns out botched. Comparing our 'uname' info: uname -m = i686 uname -r = 1.0.17(0.48/3/2) -uname -s = MINGW32_NT-5.1 +uname -s = MINGW32_NT-6.0 uname -v = 2011-04-24 23:39 we see that everything is exactly the same, except for 'uname -s'. I presume that's merely a reflection of different operating systems (XP versus Vista). We probably need some assistance from someone with a better understanding of how this config file is supposed to be generated. Cheers, Rob ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
I've tried building on another XP machine and got the same results (i.e. config.h is a direct copy of config.h.in). I'm starting to think the problem might be with MinGW and the fact that uname -s returns MINGW32_NT-5.1. I will post on the MinGW support forum for help. Thanks, Armin On 8/18/2011 at 12:26 AM, Sisyphus sisyph...@optusnet.com.au wrote: = I don't understand it all that well either, but I believe your understanding is basically correct. In addition to the gcc-3.4.5 that I used yesterday, I also have the very same setup that you have - namely the one installed by mingw-get-inst-20110802.exe. When I use that, a correct config.h is still being created for me I'm fairly sure that your only problem is that your config.h is not being generated correctly ... and I have no idea why that happens. The only differences in our config.log files is the things you would expect to see as the result of having been run on different machines, different pathnames, etc. I can see nothing that explains the reason that your config.h turns out botched. Comparing our 'uname' info: uname -m = i686 uname -r = 1.0.17(0.48/3/2) -uname -s = MINGW32_NT-5.1 +uname -s = MINGW32_NT-6.0 uname -v = 2011-04-24 23:39 we see that everything is exactly the same, except for 'uname -s'. I presume that's merely a reflection of different operating systems (XP versus Vista). We probably need some assistance from someone with a better understanding of how this config file is supposed to be generated. Cheers, Rob ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
Thanks David, I played around with the PATH variable and took out everything other than the standard windows directories, all to no avail. I also checked which sed and awk are called, they are the ones from MinGW/msys/1.0/bin: $ which sed /bin/sed.exe $ which awk /bin/awk.exe $ sed --version GNU sed version 4.2.1 $ awk --version GNU Awk 3.1.7 I do have a cygwin installation, but the awk and sed are older versions (3.1.6 and 4.1.5, respectively). I'm positive I tried ./configure without cygwin in my PATH. Are there any other tools used (other than awk and sed) by ./configure? Thanks, Armin On 8/18/2011 at 09:11 AM, David Komanek address@hidden wrote: Hi, what are the PATH variables on your systems ? Once I had experienced similar problem with different package using ruby gems and I resolved it by reorganizing PATHs. Some binaries were called from CygWin installation, other ones from MinGW Maybe it is not your case, but check the Windows PATH variable to be sure. David ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
Thanks for the link John. That's great. I still wouldn't mind to find out what went wrong, since I already invested quite a few hours in this. --Armin On 8/16/2011 at 8:34 PM, John Chludzinski john.chludzin...@gmail.com wrote: Another option: http://ascend4.org/Binary_installer_for_GSL-1.13_on_MinGW. On Tue, Aug 16, 2011 at 4:57 PM, Armin Armbruster aarmb...@ndigital.comwrote: ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
If you're using GSL, I would seriously suggest you take a look at LAPACK for linear algebra routines. GSL is literally orders of magnitude slower than LAPACK. (It took me 15hrs to solve a generalized eigenvalue problem using GSL and ~4 min. using LAPACK.) For LAPACK use GotoBLAS2 (http://www.tacc.utexas.edu/tacc-projects/gotoblas2). Builds easily with MinGW. BTW, you'll need to add wget to the bin folder in MinGW. ---John On Wed, Aug 17, 2011 at 9:02 AM, Armin Armbruster aarmb...@ndigital.comwrote: Thanks for the link John. That's great. I still wouldn't mind to find out what went wrong, since I already invested quite a few hours in this. --Armin On 8/16/2011 at 8:34 PM, John Chludzinski john.chludzin...@gmail.com wrote: Another option: http://ascend4.org/Binary_installer_for_GSL-1.13_on_MinGW. On Tue, Aug 16, 2011 at 4:57 PM, Armin Armbruster aarmb...@ndigital.comwrote: ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
- Original Message - From: Armin Armbruster aarmb...@ndigital.com To: help-gsl@gnu.org; Sisyphus sisyph...@optusnet.com.au Sent: Thursday, August 18, 2011 4:02 AM Subject: Re: [Help-gsl] Building gsl-1.15 under MinGW Hi Rob, Thanks for your reply. here's gcc -v: $ gcc -v Using built-in specs. COLLECT_GCC=C:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --wi th-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r untime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.2 (GCC) Some more background: - I'm using the latest MinGW (downloaded from http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/), mingw-get-inst-20110802.exe). - $ help ==GNU bash, version 3.1.17(1)-release (i686-pc-msys) - my host OS is MS Windows XP, SP3 - gsl downloaded from ftp://ftp.gnu.org/gnu/gsl/gsl-1.15.tar.gz Last night I've tried to build the same gsl on my computer at home (running Windows 7 Home Premium, SP1, 64 bit OS). I used the same MinGW installer and the same GSL package and make ran without problems. I compared the config.log files in both cases (see attachment config_log_diff.txt). The only significant difference that I can see is that uname -s returns MINGW32_NT-5.1 on the XP machine and MINGW32_NT-6.1 on the Win7 machine. The one thing I noticed is, that the resulting config.h is a direct copy of config.h.in!!! The only difference is the first line added to config.h. That makes me believe that something with awk and/or sed isn't working properly. I don't have a full understanding of the configure script but from what I understand it is taking the config.h.in file as a template and mangles it based on some test results to turn on some of the defines. Is that right? = I don't understand it all that well either, but I believe your understanding is basically correct. In addition to the gcc-3.4.5 that I used yesterday, I also have the very same setup that you have - namely the one installed by mingw-get-inst-20110802.exe. When I use that, a correct config.h is still being created for me I'm fairly sure that your only problem is that your config.h is not being generated correctly ... and I have no idea why that happens. The only differences in our config.log files is the things you would expect to see as the result of having been run on different machines, different pathnames, etc. I can see nothing that explains the reason that your config.h turns out botched. Comparing our 'uname' info: uname -m = i686 uname -r = 1.0.17(0.48/3/2) -uname -s = MINGW32_NT-5.1 +uname -s = MINGW32_NT-6.0 uname -v = 2011-04-24 23:39 we see that everything is exactly the same, except for 'uname -s'. I presume that's merely a reflection of different operating systems (XP versus Vista). We probably need some assistance from someone with a better understanding of how this config file is supposed to be generated. Cheers, Rob ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building gsl-1.15 under MinGW
Another option: http://ascend4.org/Binary_installer_for_GSL-1.13_on_MinGW. On Tue, Aug 16, 2011 at 4:57 PM, Armin Armbruster aarmb...@ndigital.comwrote: Hi all, I'm trying to build gsl-1.15 under MinGW and are having some problems. I was following the instructions from INSTALL. After running ./configure and make the compiler stops at infnan.c with the following error message: infnan.c:98:3: error: #error cannot define gsl_finite without HAVE_DECL_FINITE or HAVE_IEEE_COMPARISONS infnan.c:115:3: error: #error cannot define gsl_isnan without HAVE_DECL_ISNAN or HAVE_IEEE_COMPARISONS I would appreciate any input on how to proceed from here. The full output from ./configure and make can be found below. Thanks in advance, Armin $ ./configure checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for a sed that does not truncate output... /bin/sed checking whether make sets $(MAKE)... (cached) yes checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking whether ln -s works... no, using cp -p checking how to print strings... printf checking for a sed that does not truncate output... (cached) /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /mingw/bin/nm checking the name lister (/mingw/bin/nm) interface... BSD nm checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32 checking how to convert i686-pc-mingw32 file names to toolchain format... func_convert_file_msys_to_w32 checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_implib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /mingw/bin/nm output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... no checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for size_t... yes checking for working volatile... yes checking for inline... inline checking whether char is unsigned... no checking for cos in -lm... yes checking for GNU-style extern inline... yes checking ieeefp.h usability... no checking ieeefp.h presence... no checking for ieeefp.h... no checking for vprintf... yes checking for _doprnt... no checking for
Re: [Help-gsl] Building gsl-1.15 under MinGW
- Original Message - From: Armin Armbruster aarmb...@ndigital.com To: help-gsl@gnu.org Sent: Wednesday, August 17, 2011 6:57 AM Subject: [Help-gsl] Building gsl-1.15 under MinGW Hi all, I'm trying to build gsl-1.15 under MinGW and are having some problems. I was following the instructions from INSTALL. After running ./configure and make the compiler stops at infnan.c with the following error message: infnan.c:98:3: error: #error cannot define gsl_finite without HAVE_DECL_FINITE or HAVE_IEEE_COMPARISONS infnan.c:115:3: error: #error cannot define gsl_isnan without HAVE_DECL_ISNAN or HAVE_IEEE_COMPARISONS Rather strange. When I build with MinGW (gcc-3.4.5) in my msys shell, there's no problem. A diff on our configure outputs is attached (the '-' is what the OP had, the '+' is what I had). Perhaps that rings a bell for someone here doesn't ring any bells for me, but :-) Perhaps of more siginificance is the contents of (the generated) gsl-1.15/config.h. You should be able to find the following line in that file: #define HAVE_DECL_FINITE 1 And you should also be able to find this line: #define HAVE_IEEE_COMPARISONS 1 Does your gsl-1.15/config.h contain those lines ? (Your configure output suggests that you should at least have the first.) What does 'gcc -v' output for you ? Cheers, Rob --- conf0.txt Wed Aug 17 13:01:58 2011 +++ conf.txtWed Aug 17 13:01:04 2011 -checking whether the shell understands +=... yes +checking whether the shell understands +=... no -checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL +checking how to recognize dependent libraries... file_magic file format (pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64) -checking how to associate runtime and link libraries... func_cygming_dll_for_implib +checking how to associate runtime and link libraries... func_cygming_dll_for_implib_fallback -checking for mt... mt +checking for mt... no ___ Help-gsl mailing list Help-gsl@gnu.org https://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Building GSL 1.7 on AIX using xlc
Hi, I managed to build GSL using gxlc (an interface to xlc using gcc command line options - as far as I understood). Mathias On Friday 17 February 2006 18:01, Brian Gough wrote: Mathias Wagner writes: I am trying to build gsl on an IBM power 5 machine running AIX 5.2 using xlc Making all in utils /bin/sh ../libtool --mode=link xlc -O -qmaxmem=8192 -Wl,-bbigtoc -o libutils.la placeholder.lo -lm rm -fr .libs/libutils.la .libs/libutils.* .libs/libutils.* ar cru .libs/libutils.a placeholder.o ar: 0707-126 placeholder.o is not valid with the current object file mode. Use the -X option to specify the desired object mode. make: 1254-004 The error code from the last command is 1. Does anyone know what this means? What happens if you use make -k ? Can you compile other directories ok or do they all have this problem? -- // *** // ** Mathias Wagner** // ** Institut fuer Kernphysik, TU Darmstadt** // ** Schlossgartenstr. 9, 64289 Darmstadt, Germany ** // ** ** // ** email: [EMAIL PROTECTED] ** // ** www : http://crunch.ikp.physik.tu-darmstadt.de/~wagner ** // *** ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
