Bad path on removal of libatomic causing compilation failure

[Anubis 1101]

That did it, it was the directory. Thanks for your help, both of you. It seems I've still got a lot to learn about
this stuff, but at least now I can do it with GCC 16 (apparently? I swear it said 15.1...) instead of GCC 11, which
is what I had been using.

Also, a curious side note, when I mkdir a directory, and then cd into it, it returns a directory to the trash
folder on the drive instead. If I had to guess, this is probably because it's an NTFS partition, for shared files 
between my main Linux partition and my Windows partition, where I keep most of my active projects. It's not a problem
or anything, I can still just use the GUI file browser to do it manually, I just thought it was strange.





On Saturday, November 15th, 2025 at 12:58 AM, Basile Starynkevitch <basile@starynkevitch.net> wrote:

> 
> 
> 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