GCC ignores sysroot
$ gcc --sysroot=/wrongpath -xc++ -I /usinclude/qt5 -E -v - Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-10ubuntu2' --with-bugurl=file:///usshare/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/uslib --without-included-gettext --enable-threads=posix --libdir=/uslib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2) COLLECT_GCC_OPTIONS='-I' '/usinclude/qt5' '-E' '-v' '-mtune=generic' '-march=x86-64' /uslib/gcc/x86_64-linux-gnu/9/cc1plus -E -quiet -v -I /usinclude/qt5 -imultiarch x86_64-linux-gnu -isysroot /wrongpath -D_GNU_SOURCE - -mtune=generic -march=x86-64 -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection ignoring duplicate directory "/usinclude/x86_64-linux-gnu/c++/9" ignoring nonexistent directory "/wrongpath/uslocal/include/x86_64-linux-gnu" ignoring nonexistent directory "/wrongpath/uslocal/include" ignoring nonexistent directory "/uslib/gcc/x86_64-linux-gnu/9/include-fixed" ignoring nonexistent directory "/uslib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include" ignoring nonexistent directory "/wrongpath/usinclude/x86_64-linux-gnu" ignoring nonexistent directory "/wrongpath/usinclude" ignoring nonexistent directory "/usinclude/qt5" #include "..." search starts here: #include <...> search starts here: /usinclude/c++/9 /usinclude/x86_64-linux-gnu/c++/9 /usinclude/c++/9/backward /uslib/gcc/x86_64-linux-gnu/9/include End of search list.
Can't get it to Iook up /wrongpath/usinclude/qt5. Shouldn't this work?
submitted by CrazyJoe221
A quick motivation to commit often
This is my story on how making consistent commits really saved me.
I built out a developer portfolio about 2-3 months ago, and I thought to myself, "Should I really bother making lots of commits and branching off features? I'm the only one working on this and it's gonna be a pretty short project with very little future maintenance." But, as per the internet's suggestion, I (begrudgingly) did it.
Of course, during development I ran into bugs, as we all do. After fixing the bug, I'd make a commit. I got the site to a state I was happy with and left it there.
Two months after (AKA now), I'm working on a different site using (more or less) the same tech stack. And guess what? I ran into a very weird and obscure bug. The internet had little advice on it, because as I found out the issue was related to two technologies clashing with each other. It was also a bug that only showed up in the build version, which made debugging a looooot slower. So, I was in a bit of a pickle.
Or, I would have been, if I hadn't encountered and solved this exact same
bug two months ago on my dev portfolio. Of course, 60 days and thousands of lines of code later I couldn't remember what I did. "Crap", I thought to myself, "I don't remember how I fixed this". But then, a lightbulb went off. A lightbulb going by the name of "git commit -m".
So, I went to my github repo of the previous project, opened the commits page, and searched it for "strange bug" (I specifically remember labelling the commit something like that because the bug was so odd). I found it, and since I was committing consistently for every feature I made or bug I fixed, the only thing in that commit was that bug fix. This made it super easy to see exactly what I needed to do. I applied it to my current project and, in a very short amount of time and no debugging, the issue was gone.
So that's how making consistent commits with good messages attached (well, memorable messages anyways) saved me from debugging the same weird, obscure issue twice.
If people want to know what the bug was, it was an issue where having a Framer Motion
AnimatePresence component as a direct child of a Gatsby layout component completely breaks the layout, but only on build. It took me a while to figure that one out lol.
submitted by Sparlos