bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: max_align_t on RHEL 7.1 s390x


From: Sergio Durigan Junior
Subject: Re: max_align_t on RHEL 7.1 s390x
Date: Wed, 29 Aug 2018 19:44:37 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

On Wednesday, August 29 2018, Bruno Haible wrote:

> Sergio Durigan Junior wrote:
>> the specific case of the command line invocation, here's what is being
>> used:
>> 
>>   gcc -DHAVE_CONFIG_H
>> -I. -I../../../../binutils-gdb/gdb/gnulib/import -I..  -g
>> -D_GLIBCXX_DEBUG -MT glob.o -MD -MP -MF $depbase.Tpo -c -o glob.o
>> ../../../../binutils-gdb/gdb/gnulib/import/glob.c &&\
>> mv -f $depbase.Tpo $depbase.Po
>
> So, it's using 'gcc' without any '-std=...' option.
>
> By [1] it is probably a gcc version 4.8.x. By [2] it uses -std=gnu90 by 
> default.
> This explains the error messages at least.
>
> So it boils down to what Paul hinted at: Why was the 'c99' module not
> effective? For this, it would be good if you could attach config.log
> (config.status and config.cache are not sufficient for analyzing this).

I managed to reproduce this bug, and also to find the reason for it.

Basically, the gnulib machinery to identify the compiler features and
modify its flags is working OK, as can be seen by this excerpt from
gnulib/Makefile:

  ...
  CC=gcc -std=gnu11
  ...

Also, if I enter the gnulib build directory (which, for GDB, is located
at "gdb/build-gnulib/") and run "make", everything works fine.  The
problem happens when GDB's Makefile invokes gnulib's.  Here's how it
works.

GDB's Makefile uses this incantation to build gnulib:

  all-lib: $(GNULIB_BUILDDIR)/Makefile
          @$(MAKE) $(FLAGS_TO_PASS) DO=all DODIRS=$(GNULIB_BUILDDIR) subdir_do
  .PHONY: all-lib

The "subdir_do" rule is:

  subdir_do: force
          @for i in $(DODIRS); do \
                  ...
                  if [ -f ./$$i/Makefile ] ; then \
                          if (cd ./$$i; \
                                  $(MAKE) $(FLAGS_TO_PASS) $(DO)) ; then true ; 
\
                          else exit 1 ; fi ; \
                  else true ; fi ; \
          done

Which is correct, and should work at first glance.  However,
FLAGS_TO_PASS contains:

  FLAGS_TO_PASS = \
          ...
          "CC=$(CC)" \
          "CFLAGS=$(CFLAGS)" \
          "CXX=$(CXX)" \
          "CXX_DIALECT=$(CXX_DIALECT)" \
          "CXXFLAGS=$(CXXFLAGS)" \
          ...

Which ends up overriding gnulib's CC/CXX variables.  That's why we don't
see the "-std=gnu11" there.

A possible workaround would be to have a version of FLAGS_TO_PASS which
doesn't include CC/CXX.  The user would still be able to specify a
CC/CXX when invoking the toplevel configure script to compile GDB, but
she would lose the ability to specify it directly with "make" (unless
she enters the gdb/build-gnulib/ directory first).  I thought about
solving this on gnulib's side, by check if CC/CXX are defined first, but
there are problems with this approach:

1) If CC/CXX are not defined, then we can stick to the current behaviour
and append "-std=gnu11" if needed.

2) If CC/CXX are defined, then the test for "-std=gnu11" is rendered
useless, because we know nothing about the new CC/CXX being provided.
In this case, we wouldn't be able to specify "-std=gnu11" or any other
flags, and, at least in this specific case (for GDB), things would still
break.

Unless someone has a better idea, I'll propose a patch to not pass
CC/CXX to gnulib's Makefile on GDB.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]