On Thu, 20 Jan 2022 at 13:24, Ryan Schmidt wrote:
> If gnulib starts requiring a compiler newer than Apple gcc 4.2.1, that will
> be problem for MacPorts on 10.6 and earlier. We might be able to bootstrap
> our way to a newer compiler, but that wouldn't be possible if the newer
> compiler or
On Thu, Jan 20, 2022 at 8:24 AM Ryan Schmidt wrote:
>
> > On Jan 18, 2022, at 15:18, Reuben Thomas wrote:
> >
> > On Tue, 18 Jan 2022 at 20:56, Jeffrey Walton wrote:
> >>
> >> If you are OS X 10.8 and above, then you will likely be using Apple
> >> Clang (or LLVM Clang), and you likely won't
> On Jan 18, 2022, at 15:18, Reuben Thomas wrote:
>
> On Tue, 18 Jan 2022 at 20:56, Jeffrey Walton wrote:
>>
>> If you are OS X 10.8 and above, then you will likely be using Apple
>> Clang (or LLVM Clang), and you likely won't have troubles.
You will likely be using clang on 10.7 and
On Tue, 18 Jan 2022 at 20:56, Jeffrey Walton wrote:
>
> If you are OS X 10.8 and above, then you will likely be using Apple
> Clang (or LLVM Clang), and you likely won't have troubles.
>
> OS X 10.6 switched to llvm-gcc. It should not have a problem with
> inline.
On Tue, Jan 18, 2022 at 2:54 PM Reuben Thomas wrote:
>
> On Tue, 18 Jan 2022 at 18:38, Paul Eggert wrote:
> >
> > I'm not sure a newer compiler would fix the bugs, as they're typically
> > present in the ctype.h supplied by the OS. If the newer compiler comes
> > with a fixed ctype.h you're OK;
On Tue, 18 Jan 2022 at 18:38, Paul Eggert wrote:
>
> I'm not sure a newer compiler would fix the bugs, as they're typically
> present in the ctype.h supplied by the OS. If the newer compiler comes
> with a fixed ctype.h you're OK; if it reuses or copies the old ctype.h
> you'll have a problem.
I
On 1/18/22 04:54, Reuben Thomas wrote:
I solved my problem not by using the updated gnulib, but by
assuming a conformant C99 compiler, and directly using the "inline"
keyword. This would not work on clang as shipped with old Mac OS; is
it reasonable in your view for me to expect users on such
On Tue, 18 Jan 2022 at 01:58, Ryan Schmidt wrote:
> MacPorts itself still runs on Mac OS X 10.4 and later and we do still have a
> number of users using older systems. More so than with other operating
> systems, I think, Mac users care about support for older OS versions because
> Apple
On Mon, 17 Jan 2022 at 22:22, Reuben Thomas wrote:
>
> On Mon, 17 Jan 2022 at 22:14, Paul Eggert wrote:
> >
> > Although the workaround still functions on current macOS, it's better to
> > use proper inline functions when available so I installed the attached
> > patch into Gnulib. Please give
On Jan 17, 2022, at 16:14, Paul Eggert wrote:
> That part of Gnulib was introduced in 2013:
>
> https://lists.gnu.org/r/bug-gnulib/2013-11/msg00045.html
>
> and as I vaguely recall was in response to this macports ticket:
>
> https://trac.macports.org/ticket/41033
> I don't know whether
On Mon, Jan 17, 2022 at 5:14 PM Paul Eggert wrote:
>
> On 1/17/22 10:37, Reuben Thomas wrote:
>
> > "extern-inline" copies a stanza of code into
> > config.h. That code includes a test of the preprocessor macro
> > "__header_inline". That macro is defined in a system header on macOS.
> > When
On Mon, 17 Jan 2022 at 22:14, Paul Eggert wrote:
>
> Although the workaround still functions on current macOS, it's better to
> use proper inline functions when available so I installed the attached
> patch into Gnulib. Please give it a try.
Thanks, I will.
> I don't know whether the macOS
On 1/17/22 10:37, Reuben Thomas wrote:
"extern-inline" copies a stanza of code into
config.h. That code includes a test of the preprocessor macro
"__header_inline". That macro is defined in a system header on macOS.
When config.h is #included, no other header has been included.
Therefore, the
On Mon, 17 Jan 2022 at 17:41, Paul Eggert wrote:
>
> Could you give complete instructions from scratch, to reproduce the
> config.h that has this problem? Without that, it'll be hard for us to
> understand or fix the problem.
Sorry, I've failed to explain the problem clearly (or maybe there's a
On 1/17/22 04:50, Reuben Thomas wrote:
Please, to help us reproduce the issue and verify a potential fix:
How to reproduce the issue? I.e. What did you try to do, and what were
the resulting diagnostics?
$ gcc -dM -E config.h | grep GL_EXTERN
#define _GL_EXTERN_INLINE static _GL_UNUSED
#define
On Mon, 17 Jan 2022 at 12:37, Bruno Haible wrote:
>
> Please, to help us reproduce the issue and verify a potential fix:
> How to reproduce the issue? I.e. What did you try to do, and what were
> the resulting diagnostics?
$ gcc -dM -E config.h | grep GL_EXTERN
#define _GL_EXTERN_INLINE static
Hi Reuben,
> The definition of _GL_EXTERN_INLINE relies, on macOS, on
> __header_inline, which is not a compiler built-in, but is defined in
> sys/cdefs.h. Therefore, __header_inline is not defined when config.h
> is included, and the tests always assume, on macOS, that the compiler
> is buggy
The definition of _GL_EXTERN_INLINE relies, on macOS, on
__header_inline, which is not a compiler built-in, but is defined in
sys/cdefs.h. Therefore, __header_inline is not defined when config.h
is included, and the tests always assume, on macOS, that the compiler
is buggy and does not support
18 matches
Mail list logo
