[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-06 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #1 from Andrew Pinski  ---
>-I /FaF/glibc/include

Use -isystem instead or a true sysroot instead.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-06 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #2 from Peter VARGA  ---
Sorry, but this does not help.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-06 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #3 from Peter VARGA  ---
(In reply to Andrew Pinski from comment #1)
> >-I /FaF/glibc/include
> 
> Use -isystem instead or a true sysroot instead.

Sorry, but this does not help.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-06 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #4 from Peter VARGA  ---
(In reply to Andrew Pinski from comment #1)
> >-I /FaF/glibc/include
> 
> Use -isystem instead or a true sysroot instead.

Can you post the full g++ command line options how you mean it?

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-06 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #5 from Marc Glisse  ---
That's not how you use a different glibc. If you look at the include order
printed by -v, it has to remain in that order (libstdc++ before glibc, in
particular), whereas you are adding your glibc in front. Best would be to
recompile gcc, which has the added advantage that it will be able to take
advantage of the new features in the new glibc this way.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-06 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #6 from Peter VARGA  ---
(In reply to Marc Glisse from comment #5)
> That's not how you use a different glibc. If you look at the include order
> printed by -v, it has to remain in that order (libstdc++ before glibc, in
> particular), whereas you are adding your glibc in front. Best would be to
> recompile gcc, which has the added advantage that it will be able to take
> advantage of the new features in the new glibc this way.

May be for you all is clear but I am not in the gnu gcc developer team and I am
using only gcc. Therefore I don't really understand what I should do. You all
give just half of some hints and they don't even work.

What should I do different when I recompile gcc?

This works - but why should I do it? Why is g++ using the path /usr/include
BEFORE the others and this is the problem! gcc does NOT keep the include order.

g++ foo.cpp -o foo -nostdinc -I /FaF/include/c++/7.3 -I
/FaF/include/c++/7.3/x86_64-suse-linux/ -I /FaF/glibc/include/ -I
/FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include

In /FaF is my gcc 7.3 and in /FaF/glibc is glibc 2.27

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-07 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #7 from Peter VARGA  ---
This is the original version:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

Before I found now finally a solution I had to sort out the order - it was not
really that trivial and very annoying.

This is now how it works and - as it should be - the order of the include files
in the project does NOT matter anymore.
BUT, it is very important that /usr/include is last in the list, otherwise it
won't compile:

-nostdinc
-I /FaF/curl/include
-I /usr/include/mysql
-I /FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include-fixed
-I /FaF/include/c++/7.3
-I /FaF/include/c++/7.3/x86_64-suse-linux/
-I /FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include
-I /FaF/glibc/include/
-I /usr/include

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-07 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #8 from Jonathan Wakely  ---
You need to recompile gcc telling it to use the new glibc.

When GCC is built it creates fixed dependencies on the C library. You can't
just point it to a new libc and expect it to work. A new C library needs a new
compiler as well.

So build GCC (see https://gcc.gnu.org/wiki/InstallingGCC for a starting point)
and add --with-native-system-header-dir=/FaF/glibc/include/ to the configure
options.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-07 Thread wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #9 from Jim Wilson  ---
Building and using glibc is complicated.  It is best to refer to a FAQ if you
haven't done this before.  You can find some info on the glibc wiki about this
here:
   https://sourceware.org/glibc/wiki/Testing/Builds
You probably want item 5.

It is a little simpler if you build a gcc that is set up to use your glibc
build, which requires building a complete toolchain from scratch.  If you want
to learn how to do this, it is best to look at someone else's scripts showing
how to do it.  Every linux distro has scripts for this.  I like to use
crosstools-ng.  You can find some info on how to build a toolchain here:
 https://crosstool-ng.github.io/docs/toolchain-construction/
and look at the scripts if you want the details of how this works.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-31 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #10 from Peter VARGA  ---
(In reply to Jonathan Wakely from comment #8)
> You need to recompile gcc telling it to use the new glibc.
> 
> When GCC is built it creates fixed dependencies on the C library. You can't
> just point it to a new libc and expect it to work. A new C library needs a
> new compiler as well.
> 
> So build GCC (see https://gcc.gnu.org/wiki/InstallingGCC for a starting
> point) and add --with-native-system-header-dir=/FaF/glibc/include/ to the
> configure options.

The option --with-native-system-header-dir=/FaF/glibc/include/ didn't work.
Now, the include errors appear while compiling gcc.

Below some extract.

I am working on SLES 12 SP3 - the system glibc version is 2.22. OK it is 3
years old.
I am using the newest glibc version 2.27 only for my project.

The question is if I really need the newest version. It makes the whole process
only too complicated.



In file included from /FaF/glibc/include/errno.h:28:0,
 from ../../../gcc-7.3.0/libgcc/../gcc/tsystem.h:93,
 from ../../../gcc-7.3.0/libgcc/libgcc2.c:27:
/FaF/glibc/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file
or directory
 # include 
   ^~~
In file included from /FaF/glibc/include/errno.h:28:0,
 from ../../../gcc-7.3.0/libgcc/../gcc/tsystem.h:93,
 from ../../../gcc-7.3.0/libgcc/libgcov.h:42,
 from ../../../gcc-7.3.0/libgcc/libgcov-interface.c:26:
/FaF/glibc/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file
or directory
 # include 
   ^~~
In file included from /FaF/glibc/include/errno.h:28:0,
 from ../../../gcc-7.3.0/libgcc/../gcc/tsystem.h:93,
 from ../../../gcc-7.3.0/libgcc/libgcov.h:42,
 from ../../../gcc-7.3.0/libgcc/libgcov-merge.c:26:

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-03-31 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #11 from Andreas Schwab  ---
The glibc headers depend on the kernel UAPI headers, they need to be available
in the sysroot.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-04-22 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #12 from Andrew Pinski  ---
This build works for me so closing.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-04-22 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

Peter VARGA  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |---

--- Comment #13 from Peter VARGA  ---
(In reply to Andrew Pinski from comment #12)
> This build works for me so closing.

Any chance you could be more specific?

For me it doesn't work and I think the goal should be to provide as much
information as possible so other none-gcc-glibc-experts have a chance to use
these tools - or?

I have in the 1st comment an MCVE which I doesn't compile with the default
settings. OK, I got the hint to compile gcc with the glibc version - but this I
am not capable and I asked for additional information.

What came I don't understand

Any effort to solve this?

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-23
 Ever confirmed|0   |1

--- Comment #14 from Jonathan Wakely  ---
Installing your own glibc in a new location and trying to point GCC to it with
-I /FaF/glibc/include is not "the default settings".

As has been explained, you need to rebuild GCC to use the new glibc. To do that
you also need the Linux kernel headers in the same sysroot tree, i.e.
/FaF/glibc

Did you try that yet?

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2018-04-23 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #15 from Peter VARGA  ---
(In reply to Jonathan Wakely from comment #14)
> Installing your own glibc in a new location and trying to point GCC to it
> with -I /FaF/glibc/include is not "the default settings".
> 
> As has been explained, you need to rebuild GCC to use the new glibc. To do
> that you also need the Linux kernel headers in the same sysroot tree, i.e.
> /FaF/glibc
> 
> Did you try that yet?

It would be very much appreciated if you could provide me the missing settings
for my configure command line arguments which look for the moment like this:

--prefix=/FaF --infodir=/FaF/share/info --mandir=/FaF/share/man
--libdir=/FaF/lib64 --libexecdir=/FaF/lib64 --enable-languages=c,c++ 
--enable-checking=release --with-gmp=/FaF/ --with-mpfr=/FaF --with-gmc=/FaF
--with-gxx-include-dir=/FaF/include/c++/7.3 --enable-ssp --disable-libssp
--disable-plugin --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-7.3 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux --disable-multilib

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

2021-05-29 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #16 from Andrew Pinski  ---
Closing as works for me because the way the glibc/gcc build works is something
which usually done by using a slightly different triplet (using a different
vendor is one simple way of how doing it).