Bad path on removal of libatomic causing compilation failure

[Basile Starynkevitch]

On Sat, 2025-11-15 at 05:19 +0000, Sam James via Gcc-help wrote:
> Anubis 1101 via Gcc-help <gcc-help@gcc.gnu.org> writes:
> 
> > The full configure line was just "./configure". The first time around, I didn't use any special modifiers.
> > I did run it a few times, and experimented with using the prefix
> > command and a few others to see if I could change things, but at best
> > it still just ran for 20 or so minutes, and then exited with "Error
> > 2".
> 
> I wonder if you're building in-tree? Are you running `./configure`
> inside of your git checkout directly, or within a subdirectory you
> create?


The GCC documentation explicitly forbids in-tree build.  https://gcc.gnu.org/install/configure.html

For what it is worth, on a Debian/Linux/forky/sid desktop computer with AMD Ryzen Threadripper 2970WX
(and SSD disk, and 64Gbytes of RAM) I successfully build GCC doing the following:

I did clone the GCC source under /usr/src/Lang/gcc-trunk
(that takes about 2.8 gigabytes of disk space). Specifically I am compiling the following commit of GCC

commit 4b84e561856599f82ce8f12a876ade388d5db330 (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
Author: Jason Merrill <jason@redhat.com>
Date:   Fri Nov 14 17:52:57 2025 +0530

    c++/modules: fix hash_map issue
    
    Building std.compat.cc was crashing for me because we would first get a
    pointer into imported_temploid_friends, then insert a new entry, causing the
    hash_map to expand, and then dereference the pointer into the former
    location of the hash table.  Fixed by dereferencing the pointer before
    inserting rather than after.
    
    gcc/cp/ChangeLog:
    
            * module.cc (transfer_defining_module): Dereference
            pointer into hash_map before possible insertion.

M       gcc/cp/module.cc



I did an mkdir /usr/src/Lang/_BuildGccTrunk (to contain the build tree) in which I did run
 '/usr/src/Lang/gcc-trunk/configure'   '-v' '--prefix=/usr/local' '--with-gcc-major-version-only' \
      '--program-suffix=-trunk' '--enable-shared' '--enable-plugin' '--enable-default-pie' '--with-system-zlib' \
      '--disable-multilib' '--with-tune=native' '--enable-checking=release' '--enable-host-shared' \
      '--build=x86_64-linux-gnu' '--host=x86_64-linux-gnu' '--target=x86_64-linux-gnu' \
      '--enable-languages=c,c++,jit,lto'  'CFLAGS=-g -O2' 'CXXFLAGS=-g -O2'

Then I ran make -j5 (using GNU make 4.4.1). Actually I have some temporary hardware issue (faulty RAM or cosmic rays) 
and the first make failed, but a second one succeeded.

Of course the GCC build is bootstrapping (the compiler is recompiling itself, and that is a serious test).

Than I ran (in /usr/src/Lang/_BuildGccTrunk ...) make install DESTDIR=/tmp/gccinst

The obtained /tmp/gccinst has 2202 megabytes.

Finally I did sudo /bin/cp -va /tmp/gccinst/usr/local/. /usr/local/.

Of course I had to run appropriate ldconfig after that.

NB. I do recommend explicit --enable-plugin when configuring your GCC

-- 

Basile STARYNKEVITCH                    basile AT starynkevitch DOT net
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250