Re: [lfs-support] glibc compilation error (in chroo environmentt)

[Pierre Labastie]

On 21/07/2017 06:29, Michael Shell wrote:
> [...] 
> And watch out that in GCC pass 2 you started with a fresh unpacking
> of the gcc tarball. (We have to do this, right?) After all, in the
> Libstdc++-7.1.0 a ../libstdc++-v3/configure --disable-libstdcxx-threads
> had been done in the pass 1 tarball's libstdc++-v3 subdirectory. Does
> anyone know if those libstdc++ configure settings will remain or be
> properly overridden if gcc's main directory configure is run - e.g.,
> what if the LFS builder attempts to start gcc pass 2 with the existing
> unpacked gcc tar ball from pass 1?
> 

I'd say it is enough to remove the "build" directory. But if you keep the
"build" directory, i'd say you are calling for trouble.

> 
> A question I now have is: At what point in the build process can
> the LFS system (i.e., gcc) be expected to be able to compile the
> thread.cc test above?
> 
> Is it after GCC-7.1.0 Pass 2, or is it only after the final build
> of GCC?

Good question. I've not tried yet, but I'd say it should be after GCC pass 2.
> 
> If the former is true, then how can GCC-7.1.0 Pass 2 have thread
> support when Glibc-2.25+adc7e06 has not yet been rebuilt (since
> just after Pass 1, and libstdc++ could not be enabled with thread
> support under that glibc)?

The beginning of chapter 1 tries to solve a (double) chicken and egg problem:

We do not want a GCC, which uses the host glibc (because it will not be
available in chroot). So we want to compile glibc in /tools before GCC. But we
want glibc to be compiled with the GCC from the book, not the one from the
host, to be sure to insulate the host from our LFS system... That's the first
chicken and egg.

So, the LFS path is to do the following: GCC pass 1 is compiled using host
tools and libraries. Then glibc using GCC pass 1, then GCC pass2 using the
just built glibc (and pass 1 tools). However, GCC source is written in C++, so
GCC needs libstdc++. But libstdc++ needs glibc. Second chicken and egg...

That's why libstdcc++ compilation for pass1 is deferred to after glibc build.
But note that the just built glibc *has* all the libraries for thread support.
It is only GCC pass1 that does not have the ability to generate code
supporting threads, so that --disable-threads needs to be passed to libstdc++
pass 1.

Now what happens for GCC pass 2? At that stage, libstdc++ and all the other
GCC support libraries are built (they use the just built glibc). The compiler
*code* does not use threads (because it was generated by GCC pass 1, which has
no thread capabilities, but the compiler *can* generate code using threads.

> And if the latter is true, how can the
> final build of glibc be expected to pass make check if doing so
> requires thread support in gcc/libstdc++ ?

I hope it is clear from the above, that the former is true.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] glibc compilation error (in chroo environmentt)

[Michael Shell]

On Thu, 20 Jul 2017 18:48:20 -0400
"Isaac D. Cohen"  wrote:

> But then I decided to try, just to make sure, and redo the second pass
> of gcc with --enable-threads. After doing that I redid the compilation of
> glibc and got the same error. So that doesn't seem to be the problem.


  Isaac,

That first URL:

https://www.mail-archive.com/gcc@gcc.gnu.org/msg81240.html

gives a test program for gcc's threads ability.

Create a file, thread.cc, which contains


#include 
int main(int, char **){
std::thread tt;
}


and then try compiling it with:

g++ -std=c++11 thread.cc -lpthread -o x

which should work without error and produce the executable "x".

If that fails, then your gcc (or should I say, libstdc++) does not have
the proper thread support.

I note that in section 5.8 for Libstdc++-7.1.0 there is:

 "--disable-libstdcxx-threads
Since we have not yet built the C threads library, the C++
one cannot be built either."

Also, note the "--with-gxx-include-dir"

This initial version of libstdc++ will/must be overwritten later by
a full version from gcc. If that does not happen and your gcc is
still using this earlier limited version of libstdc++, then it will
not have thread support from the libstdc++ library no matter how
gcc itself was configured and compiled.

And watch out that in GCC pass 2 you started with a fresh unpacking
of the gcc tarball. (We have to do this, right?) After all, in the
Libstdc++-7.1.0 a ../libstdc++-v3/configure --disable-libstdcxx-threads
had been done in the pass 1 tarball's libstdc++-v3 subdirectory. Does
anyone know if those libstdc++ configure settings will remain or be
properly overridden if gcc's main directory configure is run - e.g.,
what if the LFS builder attempts to start gcc pass 2 with the existing
unpacked gcc tar ball from pass 1?


A question I now have is: At what point in the build process can
the LFS system (i.e., gcc) be expected to be able to compile the
thread.cc test above?

Is it after GCC-7.1.0 Pass 2, or is it only after the final build
of GCC?

If the former is true, then how can GCC-7.1.0 Pass 2 have thread
support when Glibc-2.25+adc7e06 has not yet been rebuilt (since
just after Pass 1, and libstdc++ could not be enabled with thread
support under that glibc)? And if the latter is true, how can the
final build of glibc be expected to pass make check if doing so
requires thread support in gcc/libstdc++ ?


  Cheers,

  Mike




-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] glibc compilation error (in chroo environmentt)

[Bruce Dubbs]

Ken Moffat wrote:


Unless anyone has any easier suggestions, I'm going to suggest that
you start over.  If your lfs user still has the command history,
look at that before you restart, in case anything now jumps out and
says "whoops!".

For a restart, save all the sources and patches so that you don't
need to download them again. Then make a new filesystem for
/mnt/lfs.  If your distro insists on mounting the new filesystem
under /media, then get a root shell (you need that anyway during the
build, even on ubuntu which hates letting users get root shells) and
bind it to /mnt/lfs (mount --bind : man mount).


I agree with Ken.  Start over and follow the book closely.  If needed, 
install sudo on the host to help doing those commands that require root. 
We can help with the configuration if needed, but you should also be able 
to do everything needed with su.


If your distro is not cooperating, we can help overcome those issues.

One thing to keep in mind is that for testing we have automated extraction 
of the commands from the book.  The instructions in the book work without 
modification.  When you start changing things, you are likely to run into 
problems as documented in your requests for help.


  -- Bruce



--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] glibc compilation error (in chroo environmentt)

[Ken Moffat]

On Thu, Jul 20, 2017 at 06:48:20PM -0400, Isaac D. Cohen wrote:
> 
> But then I decided to try, just to make sure, and redo the second pass
> of gcc with --enable-threads. After doing that I redid the compilation of
> glibc and got the same error. So that doesn't seem to be the problem.
> 

That error is not at all common in LFS, so maybe nobody knows the
answer.

I think you said that gcc wasn't working when you went into chroot, so
you rebuilt pass2 binutils and gcc.  That destroyed any evidence
that might have been available (you didn't mention the error
message, or whatever led you to realise it wasn't working).  Your
current problems suggest that maybe there were other errors - my
first guess was that g++ had not been built correctly, but that is
just a guess.

Unless anyone has any easier suggestions, I'm going to suggest that
you start over.  If your lfs user still has the command history,
look at that before you restart, in case anything now jumps out and
says "whoops!".

For a restart, save all the sources and patches so that you don't
need to download them again. Then make a new filesystem for
/mnt/lfs.  If your distro insists on mounting the new filesystem
under /media, then get a root shell (you need that anyway during the
build, even on ubuntu which hates letting users get root shells) and
bind it to /mnt/lfs (mount --bind : man mount).

Then rerun the stuff to setup the environment, including any checks.

For the build, please remember that you need clean source for each
package, so remove the extracted directories when you move on to the
next package (particularly binutils and gcc, but also relevant for
all packages in chapter 6 that were also built in chapter 5).

And I hope your next attempt is successful.

ĸen
-- 
I live in a city. I know sparrows from starlings.  After that
everything is a duck as far as I'm concerned.  -- Monstrous Regiment
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] glibc compilation error (in chroo environmentt)

[Isaac D. Cohen]

On Tue, 18 Jul 2017 21:12:41 -0400
"Isaac D. Cohen"  wrote:

> make check. It compiled a little and then got stuck on this:
> 
> tst-thread_local1.cc: In lambda function:
> tst-thread_local1.cc:172:7: error: 'thread' is not a member of 'std'

 On Wed, 19 Jul 2017 23:29:15 -0400 Michael 
Shell wrote  

>  Isaac,

>  A google search found this:

https://www.mail-archive.com/gcc@gcc.gnu.org/msg81240.html
https://www.mail-archive.com/gcc@gcc.gnu.org/msg81257.html

>  "Yes, I finally realized I had built a GCC with '--enable-threads=no'
>  and was using that GCC to build GLIBC. Once I rebuilt GCC with threads
>  I could build GLIBC and not get this error."

>  In the book, the first pass of gcc is built without thread support, but
>  thread support should be enabled for the second pass (5.10.1).


Hi Michael,

I looked up the command I used to configure gcc on the second pass
(or perhaps the third as I redid the second pass to make gcc work in the
chroot environment) and it exactly matched the command in the book.
(I looked it up using the command gcc -v.) That is, it didn't use
--disable-threads. However, it didn't use --enable-threads either (the book
didn't say to).

But then I decided to try, just to make sure, and redo the second pass
of gcc with --enable-threads. After doing that I redid the compilation of
glibc and got the same error. So that doesn't seem to be the problem.




Thank you very much,
Isaac D. Cohen

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style