* Build problems: mpfr, mpc
@ 2021-08-20 7:58 Arjen Markus
2021-08-20 9:54 ` Richard Biener
0 siblings, 1 reply; 10+ messages in thread
From: Arjen Markus @ 2021-08-20 7:58 UTC (permalink / raw)
To: Fortran List
I am trying to build the compiler suite to test the two patches Steve Kargl
posted. But I run into a problem with the mpfr and mpc libraries: the
linker claims it cannot find them.
I checked this, in fist instance they were not present in the location they
were assumed to be, but I had copies from an earlier build, so I copied
them into the location indicated by the -L option. That does not help
though: same error messages.
How do I solve this?
Regards,
Arjen
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 7:58 Build problems: mpfr, mpc Arjen Markus
@ 2021-08-20 9:54 ` Richard Biener
2021-08-20 10:10 ` Arjen Markus
0 siblings, 1 reply; 10+ messages in thread
From: Richard Biener @ 2021-08-20 9:54 UTC (permalink / raw)
To: Arjen Markus; +Cc: Fortran List
On Fri, Aug 20, 2021 at 9:59 AM Arjen Markus via Fortran
<fortran@gcc.gnu.org> wrote:
>
> I am trying to build the compiler suite to test the two patches Steve Kargl
> posted. But I run into a problem with the mpfr and mpc libraries: the
> linker claims it cannot find them.
>
> I checked this, in fist instance they were not present in the location they
> were assumed to be, but I had copies from an earlier build, so I copied
> them into the location indicated by the -L option. That does not help
> though: same error messages.
>
> How do I solve this?
The easiest is probably to build them in-tree by means of
executing ./contrib/download_prerequesites which will download
and unpack them into your source tree.
Other than that you are likely either missing some of the requirements
or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
What host operating system are you using?
Richard.
> Regards,
>
> Arjen
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 9:54 ` Richard Biener
@ 2021-08-20 10:10 ` Arjen Markus
2021-08-20 10:55 ` Arjen Markus
0 siblings, 1 reply; 10+ messages in thread
From: Arjen Markus @ 2021-08-20 10:10 UTC (permalink / raw)
To: Richard Biener; +Cc: Fortran List
Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
>
>
> The easiest is probably to build them in-tree by means of
> executing ./contrib/download_prerequesites which will download
> and unpack them into your source tree.
>
>
Well, I do have the libraries (source and all) and I copied the built
libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
that are referred to in the link statement, so I assumed that would enable
the linker to find them.
Other than that you are likely either missing some of the requirements
> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
>
>
The odd thing is that the link statement as presented in the command window
knows where to find the libraries. Here is the (hopefully) relevant part:
g++ -std=c++11 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall
(...) ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
-L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
-L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
-L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
-L./../zlib -lz libcommon.a ../libcpp/libcpp.a -liconv
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr
What host operating system are you using?
>
> Cygwin on Windows 10
Oops, now that I copied the relevant bit of the link command, I see what I
did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs (and
ditto for mpc).
Okay, trying again!
Thanks for the reply. This ought to do it.
Regards,
Arjen
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 10:10 ` Arjen Markus
@ 2021-08-20 10:55 ` Arjen Markus
2021-08-20 12:31 ` Richard Biener
0 siblings, 1 reply; 10+ messages in thread
From: Arjen Markus @ 2021-08-20 10:55 UTC (permalink / raw)
To: Richard Biener; +Cc: Fortran List
Okay, that solved that error, now I get:
.... -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
../../../../../../libstdc++-v3/src/c++17/fs_ops.cc -o fs_ops.o
In file included from ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:58:
../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h: In
function 'const char*
std::filesystem::get_temp_directory_from_env(std::error_code&)':
../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h:601:25:
error: '::secure_getenv' has not been declared
601 | auto tmpdir = ::secure_getenv(env);
| ^~~~~~~~~~~~~
and there is a weird subdirectory under the build directory: gccd: - the
colon cannot be part of a directory name under Windows. I guess this is my
mistake, as I set the install directory to "d:/gfortran/work" - that should
become "/cygdrive/d/gfortran/work". Easily fixed, but I do not know what to
do about the first error.
Regards,
Arjen
Op vr 20 aug. 2021 om 12:10 schreef Arjen Markus <arjen.markus895@gmail.com
>:
>
>
> Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
>
>>
>>
>> The easiest is probably to build them in-tree by means of
>> executing ./contrib/download_prerequesites which will download
>> and unpack them into your source tree.
>>
>>
> Well, I do have the libraries (source and all) and I copied the built
> libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
> that are referred to in the link statement, so I assumed that would enable
> the linker to find them.
>
> Other than that you are likely either missing some of the requirements
>> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
>>
>>
> The odd thing is that the link statement as presented in the command
> window knows where to find the libraries. Here is the (hopefully) relevant
> part:
>
> g++ -std=c++11 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall
> (...) ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
> -L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
> -L./../zlib -lz libcommon.a ../libcpp/libcpp.a -liconv
> ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
>
>
> What host operating system are you using?
>>
>> Cygwin on Windows 10
>
> Oops, now that I copied the relevant bit of the link command, I see what I
> did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs (and
> ditto for mpc).
>
> Okay, trying again!
>
> Thanks for the reply. This ought to do it.
>
> Regards,
>
> Arjen
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 10:55 ` Arjen Markus
@ 2021-08-20 12:31 ` Richard Biener
2021-08-20 12:59 ` Arjen Markus
0 siblings, 1 reply; 10+ messages in thread
From: Richard Biener @ 2021-08-20 12:31 UTC (permalink / raw)
To: Arjen Markus, Jonathan Wakely; +Cc: Fortran List
On Fri, Aug 20, 2021 at 12:55 PM Arjen Markus <arjen.markus895@gmail.com> wrote:
>
> Okay, that solved that error, now I get:
>
> .... -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc -o fs_ops.o
> In file included from ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:58:
> ../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h: In function 'const char* std::filesystem::get_temp_directory_from_env(std::error_code&)':
> ../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h:601:25: error: '::secure_getenv' has not been declared
> 601 | auto tmpdir = ::secure_getenv(env);
> | ^~~~~~~~~~~~~
>
> and there is a weird subdirectory under the build directory: gccd: - the colon cannot be part of a directory name under Windows. I guess this is my mistake, as I set the install directory to "d:/gfortran/work" - that should become "/cygdrive/d/gfortran/work". Easily fixed, but I do not know what to do about the first error.
Possibly secure_getenv is not available in cygwin and for some reason
AC_CHECK_FUNCS (secure_getenv) as done by
libstdc++ configury misdetects it and/or the use site has a different
set of includes. Jonathan might know.
Note using cygwin (or mingw for that) might make GCC development more
painful than necessary. It might be
that using a WSL2 based setup is easier if you're stuck to a Windows
host. Using Linux in a virtual machine
might be another option of course.
Richard.
> Regards,
>
> Arjen
>
> Op vr 20 aug. 2021 om 12:10 schreef Arjen Markus <arjen.markus895@gmail.com>:
>>
>>
>>
>> Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
>>>
>>>
>>>
>>> The easiest is probably to build them in-tree by means of
>>> executing ./contrib/download_prerequesites which will download
>>> and unpack them into your source tree.
>>>
>>
>> Well, I do have the libraries (source and all) and I copied the built libraries (that is the content of mpfr/,libs and mpc/.libs to the locations that are referred to in the link statement, so I assumed that would enable the linker to find them.
>>
>>> Other than that you are likely either missing some of the requirements
>>> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
>>>
>>
>> The odd thing is that the link statement as presented in the command window knows where to find the libraries. Here is the (hopefully) relevant part:
>>
>> g++ -std=c++11 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
>> (...) ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs -L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs -L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp -L./../zlib -lz libcommon.a ../libcpp/libcpp.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lmpc
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lmpc
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lmpfr
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lmpfr
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lmpc
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lmpfr
>>
>>
>>> What host operating system are you using?
>>>
>> Cygwin on Windows 10
>>
>> Oops, now that I copied the relevant bit of the link command, I see what I did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs (and ditto for mpc).
>>
>> Okay, trying again!
>>
>> Thanks for the reply. This ought to do it.
>>
>> Regards,
>>
>> Arjen
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 12:31 ` Richard Biener
@ 2021-08-20 12:59 ` Arjen Markus
2021-08-20 13:09 ` Jonathan Wakely
0 siblings, 1 reply; 10+ messages in thread
From: Arjen Markus @ 2021-08-20 12:59 UTC (permalink / raw)
To: Richard Biener; +Cc: Jonathan Wakely, Fortran List
Going the WSL2 route (I am not all that familiar with WSL) or a Linux
emulation may be the way to go, indeed, but your remark triggered me to do
a bit of searching: there is some discussion about the secure_getenv()
function wrt Cygwin but there actually is a prototype for it in Cygwin's
stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define
that and see what happens.
Regards,
Arjen
Op vr 20 aug. 2021 om 14:31 schreef Richard Biener <
richard.guenther@gmail.com>:
> On Fri, Aug 20, 2021 at 12:55 PM Arjen Markus <arjen.markus895@gmail.com>
> wrote:
> >
> > Okay, that solved that error, now I get:
> >
> > .... -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
> -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
> -frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
> ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc -o fs_ops.o
> > In file included from
> ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:58:
> > ../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h: In
> function 'const char*
> std::filesystem::get_temp_directory_from_env(std::error_code&)':
> >
> ../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h:601:25:
> error: '::secure_getenv' has not been declared
> > 601 | auto tmpdir = ::secure_getenv(env);
> > | ^~~~~~~~~~~~~
> >
> > and there is a weird subdirectory under the build directory: gccd: -
> the colon cannot be part of a directory name under Windows. I guess this is
> my mistake, as I set the install directory to "d:/gfortran/work" - that
> should become "/cygdrive/d/gfortran/work". Easily fixed, but I do not know
> what to do about the first error.
>
> Possibly secure_getenv is not available in cygwin and for some reason
> AC_CHECK_FUNCS (secure_getenv) as done by
> libstdc++ configury misdetects it and/or the use site has a different
> set of includes. Jonathan might know.
>
> Note using cygwin (or mingw for that) might make GCC development more
> painful than necessary. It might be
> that using a WSL2 based setup is easier if you're stuck to a Windows
> host. Using Linux in a virtual machine
> might be another option of course.
>
> Richard.
>
> > Regards,
> >
> > Arjen
> >
> > Op vr 20 aug. 2021 om 12:10 schreef Arjen Markus <
> arjen.markus895@gmail.com>:
> >>
> >>
> >>
> >> Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
> >>>
> >>>
> >>>
> >>> The easiest is probably to build them in-tree by means of
> >>> executing ./contrib/download_prerequesites which will download
> >>> and unpack them into your source tree.
> >>>
> >>
> >> Well, I do have the libraries (source and all) and I copied the built
> libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
> that are referred to in the link statement, so I assumed that would enable
> the linker to find them.
> >>
> >>> Other than that you are likely either missing some of the requirements
> >>> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
> >>>
> >>
> >> The odd thing is that the link statement as presented in the command
> window knows where to find the libraries. Here is the (hopefully) relevant
> part:
> >>
> >> g++ -std=c++11 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall
> >> (...) ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
> -L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
> -L./../zlib -lz libcommon.a ../libcpp/libcpp.a -liconv
> ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> >>
> >>
> >>> What host operating system are you using?
> >>>
> >> Cygwin on Windows 10
> >>
> >> Oops, now that I copied the relevant bit of the link command, I see
> what I did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs
> (and ditto for mpc).
> >>
> >> Okay, trying again!
> >>
> >> Thanks for the reply. This ought to do it.
> >>
> >> Regards,
> >>
> >> Arjen
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 12:59 ` Arjen Markus
@ 2021-08-20 13:09 ` Jonathan Wakely
2021-08-20 13:11 ` Jonathan Wakely
0 siblings, 1 reply; 10+ messages in thread
From: Jonathan Wakely @ 2021-08-20 13:09 UTC (permalink / raw)
To: Arjen Markus; +Cc: Richard Biener, Fortran List
On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
>
> Going the WSL2 route (I am not all that familiar with WSL) or a Linux emulation may be the way to go, indeed, but your remark triggered me to do a bit of searching: there is some discussion about the secure_getenv() function wrt Cygwin but there actually is a prototype for it in Cygwin's stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define that and see what happens.
Don't do that. Define _GNU_SOURCE to tell Cygwin you want the GNU
extensions like secure_getenv, and then <sys/features.h> will define
__GNU_VISIBLE.
I am curious why _GNU_SOURCE would be defined during configure but not
when compiling.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 13:09 ` Jonathan Wakely
@ 2021-08-20 13:11 ` Jonathan Wakely
2021-08-20 13:17 ` Arjen Markus
0 siblings, 1 reply; 10+ messages in thread
From: Jonathan Wakely @ 2021-08-20 13:11 UTC (permalink / raw)
To: Arjen Markus; +Cc: Richard Biener, Fortran List
On Fri, 20 Aug 2021 at 14:09, Jonathan Wakely wrote:
>
> On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
> >
> > Going the WSL2 route (I am not all that familiar with WSL) or a Linux emulation may be the way to go, indeed, but your remark triggered me to do a bit of searching: there is some discussion about the secure_getenv() function wrt Cygwin but there actually is a prototype for it in Cygwin's stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define that and see what happens.
>
> Don't do that. Define _GNU_SOURCE to tell Cygwin you want the GNU
> extensions like secure_getenv, and then <sys/features.h> will define
> __GNU_VISIBLE.
As it says in <sys/features.h> ...
* The following private macros are used throughout the headers to control
* which symbols should be exposed. They are for internal use only, as
* indicated by the leading double underscore, and must never be used outside
* of these headers.
...
* __GNU_VISIBLE
* GNU extensions; enabled with _GNU_SOURCE.
>
> I am curious why _GNU_SOURCE would be defined during configure but not
> when compiling.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 13:11 ` Jonathan Wakely
@ 2021-08-20 13:17 ` Arjen Markus
2021-08-23 7:07 ` Arjen Markus
0 siblings, 1 reply; 10+ messages in thread
From: Arjen Markus @ 2021-08-20 13:17 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Richard Biener, Fortran List
Ah, thanks, I restarted the build with _GNU_SOURCE instead.
Regards,
Arjen
Op vr 20 aug. 2021 om 15:11 schreef Jonathan Wakely <jwakely.gcc@gmail.com>:
> On Fri, 20 Aug 2021 at 14:09, Jonathan Wakely wrote:
> >
> > On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
> > >
> > > Going the WSL2 route (I am not all that familiar with WSL) or a Linux
> emulation may be the way to go, indeed, but your remark triggered me to do
> a bit of searching: there is some discussion about the secure_getenv()
> function wrt Cygwin but there actually is a prototype for it in Cygwin's
> stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define
> that and see what happens.
> >
> > Don't do that. Define _GNU_SOURCE to tell Cygwin you want the GNU
> > extensions like secure_getenv, and then <sys/features.h> will define
> > __GNU_VISIBLE.
>
> As it says in <sys/features.h> ...
>
> * The following private macros are used throughout the headers to control
> * which symbols should be exposed. They are for internal use only, as
> * indicated by the leading double underscore, and must never be used
> outside
> * of these headers.
> ...
> * __GNU_VISIBLE
> * GNU extensions; enabled with _GNU_SOURCE.
>
>
> >
> > I am curious why _GNU_SOURCE would be defined during configure but not
> > when compiling.
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Build problems: mpfr, mpc
2021-08-20 13:17 ` Arjen Markus
@ 2021-08-23 7:07 ` Arjen Markus
0 siblings, 0 replies; 10+ messages in thread
From: Arjen Markus @ 2021-08-23 7:07 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Richard Biener, Fortran List
I defined both CFLAGS and CXXFLAGS as -D_GNU_SOURCE and it did the trick. I
see a number of unexpected failures in the log, so I will look into those.
But the good news is that the procedure does work.
Regards,
Arjen
Op vr 20 aug. 2021 om 15:17 schreef Arjen Markus <arjen.markus895@gmail.com
>:
> Ah, thanks, I restarted the build with _GNU_SOURCE instead.
>
> Regards,
>
> Arjen
>
> Op vr 20 aug. 2021 om 15:11 schreef Jonathan Wakely <jwakely.gcc@gmail.com
> >:
>
>> On Fri, 20 Aug 2021 at 14:09, Jonathan Wakely wrote:
>> >
>> > On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
>> > >
>> > > Going the WSL2 route (I am not all that familiar with WSL) or a Linux
>> emulation may be the way to go, indeed, but your remark triggered me to do
>> a bit of searching: there is some discussion about the secure_getenv()
>> function wrt Cygwin but there actually is a prototype for it in Cygwin's
>> stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define
>> that and see what happens.
>> >
>> > Don't do that. Define _GNU_SOURCE to tell Cygwin you want the GNU
>> > extensions like secure_getenv, and then <sys/features.h> will define
>> > __GNU_VISIBLE.
>>
>> As it says in <sys/features.h> ...
>>
>> * The following private macros are used throughout the headers to control
>> * which symbols should be exposed. They are for internal use only, as
>> * indicated by the leading double underscore, and must never be used
>> outside
>> * of these headers.
>> ...
>> * __GNU_VISIBLE
>> * GNU extensions; enabled with _GNU_SOURCE.
>>
>>
>> >
>> > I am curious why _GNU_SOURCE would be defined during configure but not
>> > when compiling.
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-08-23 7:07 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-20 7:58 Build problems: mpfr, mpc Arjen Markus
2021-08-20 9:54 ` Richard Biener
2021-08-20 10:10 ` Arjen Markus
2021-08-20 10:55 ` Arjen Markus
2021-08-20 12:31 ` Richard Biener
2021-08-20 12:59 ` Arjen Markus
2021-08-20 13:09 ` Jonathan Wakely
2021-08-20 13:11 ` Jonathan Wakely
2021-08-20 13:17 ` Arjen Markus
2021-08-23 7:07 ` Arjen Markus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).