[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3
From: |
Chun Tian (binghe) |
Subject: |
Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3 |
Date: |
Thu, 8 Feb 2024 13:31:07 +1100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 14.3; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.1 |
Greetings,
thanks for your explanation about the <stdint.h> issue. I will take a
look at the regexp you mentioned and see if I can provide a patch.
Regarding to external gmp, in my system the GMP library and headers are
installed (through MacPorts) at /opt/local/lib and /opt/local/include. I
think when I'm using GCC 13, these directories are automatically used.
But when I'm compiling with Apple's clang from Xcode, I have to let
clang know these directories. However, the following "standard" way
doesn't help:
export CFLAGS=-I/opt/local/include
export LDFLAGS=-L/opt/local/lib
With the above environment variables, and with --enable-dynsysgmp when
calling ./configure of GCL, I still got the following error messages
saying system GMP cannot be used:
> checking for gmp.h... yes
> checking for __gmpz_init in -lgmp... yes
> checking for external gmp version... good
> foo.c:1:10: fatal error: 'gmp.h' file not found
> #include "gmp.h"
> ^~~~~~~
> 1 error generated.
> Cannot use dynamic gmp lib
> checking doing configure in gmp directory...
> #
> #
> # -------------------
> # Subconfigure of GMP
> #
> #
By looking at your ways of detecting GMP in configure.in:
> if test "$enable_dynsysgmp" != "no" ; then
> AC_CHECK_HEADERS(
> [gmp.h],
> [AC_CHECK_LIB(
> [gmp],[__gmpz_init],
> [AC_MSG_CHECKING([for external gmp version])
> AC_RUN_IFELSE(
> [AC_LANG_PROGRAM(
> [[
> #include <gmp.h>
> ]],
> [[
> #if __GNU_MP_VERSION > 3
> return 0;
> #else
> return -1;
> #endif
> ]])],
> [AC_MSG_RESULT([good])
> TLIBS="$TLIBS -lgmp"
> echo "#include \"gmp.h\"" >foo.c
> echo "int main() {return 0;}" >>foo.c
> MP_INCLUDE=`cpp foo.c | $AWK '/(\/|\\\\)gmp.h/ {if (!i)
> print $3;i=1}' | tr -d '"'`
> rm -f foo.c])])])
>
> if test "$MP_INCLUDE" = "" ; then
> AC_MSG_RESULT([Cannot use dynamic gmp lib])
> fi
>
> fi
I think, when the command "cpp foo.c" was getting called, the "cpp"
(from Xcode) program still doesn't know the location of GMP headers,
unless "cpp $CFLAGS" is used instead. My following manual tests
confirmed my guess:
$ echo "#include \"gmp.h\"" >foo.c
$ echo "int main() {return 0;}" >>foo.c
$ cpp foo.c | $AWK '/(\/|\\\\)gmp.h/ {if (!i) print $3;i=1}' | tr -d '"'
foo.c:1:10: fatal error: 'gmp.h' file not found
#include "gmp.h"
^~~~~~~
1 error generated.
$ cpp $CFLAGS foo.c | $AWK '/(\/|\\\\)gmp.h/ {if (!i) print $3;i=1}' |
tr -d '"'
/opt/local/include/gmp.h
Therefore, I think you should at least put $CFLAGS inside the above
configure.in code pieces, to handle non-standard position of GMP headers
given by CFLAGS.
P.S. in you macOS Catalina environment, if you have GMP libraries
installed at /usr/local, that must be installed from Homebrew. I suggest
completely removing Homebrew because the installation location of
Homebrew has moved to /opt/ in higher versions of macOS. Its advantage
of staying at the "default" directory (/usr/local) is no more.
Regards,
Chun TIAN
On 08/02/24 02:31, Camm Maguire wrote:
> Greetings, and thannks as always for your feedback.
>
> "Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
>
>> Greetings,
>>
>> In the commit dc9eba0760dedcd3d042a408e715b38ac2222aa3 [1], I saw the
>> following line from gcl/h/compbas2.h was removed:
>>
>> diff --git a/gcl/h/compbas2.h b/gcl/h/compbas2.h
>> index 20a2b5c..cc7d87c 100755
>> --- a/gcl/h/compbas2.h
>> +++ b/gcl/h/compbas2.h
>> @@ -10,7 +10,6 @@ EXTER int Rset;
>>
>> #ifndef U8_DEFINED
>>
>> -#include <stdint.h>
>>
>> typedef int8_t i8 ;
>> typedef int16_t i16;
>
> This is a step toward securing a fricas build, which on my box at least
> is just about done. signal.h, from bsdsignal.c, conflicts with my full
> stdint on some symbol containing 'fds', which I do not need. The
> intent is to extract the needed parts in h/mstdint.h. This is an
> intermediate file removed by make, but you can look at it with 'make
> h/mstdint.h' from the top level. Apparently the regexp used there needs
> adjusting for your system.
>
>> Also note that I had to use GCC 13 instead of clang, because with clang
>> even the GMP building part doesn't success at the linking stage. (My
>> previous successful GCL 2.7.0 build was also based on GCC 13.)
>>
>
> Good to hear. I had trouble with gcc13 on Catalina which I did not
> pursue as it would not get me gprof anyway :-(. I'm using the external
> gmp library which works well -- does this not work for you? I'm
> thinking of removing the convenience copy of gmp4.
>
> Take care,
>
signature.asc
Description: OpenPGP digital signature
- macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Chun Tian (binghe), 2024/02/07
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Camm Maguire, 2024/02/07
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3,
Chun Tian (binghe) <=
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Chun Tian (binghe), 2024/02/07
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Camm Maguire, 2024/02/08
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Chun Tian (binghe), 2024/02/08
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Camm Maguire, 2024/02/08
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Chun Tian (binghe), 2024/02/08
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Camm Maguire, 2024/02/09
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Chun Tian (binghe), 2024/02/11
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Camm Maguire, 2024/02/12
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Chun Tian (binghe), 2024/02/12
- Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3, Camm Maguire, 2024/02/19