<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gcc on Roberto Selbach</title><link>https://rselbach.com/tags/gcc/</link><description>Recent content in Gcc on Roberto Selbach</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 18 Feb 2002 09:17:43 +0000</lastBuildDate><atom:link href="https://rselbach.com/tags/gcc/index.xml" rel="self" type="application/rss+xml"/><item><title>GCC 2.95 Is Part of the Platform</title><link>https://rselbach.com/gcc-295-is-part-of-the-platform/</link><pubDate>Mon, 18 Feb 2002 09:17:43 +0000</pubDate><guid>https://rselbach.com/gcc-295-is-part-of-the-platform/</guid><description>&lt;p&gt;I lost an afternoon to code that compiled perfectly on my machine and failed on the machine that actually had to ship it. Mine had a newer compiler. The other one had GCC 2.95, as do quite a few systems on which KDE software is expected to build.&lt;/p&gt;
&lt;p&gt;The useful lesson is not to argue with the compiler. It is to treat it as part of the target platform. If the project says it supports GCC 2.95, compile with GCC 2.95 before sending the change anywhere.&lt;/p&gt;
&lt;p&gt;I now keep a separate build tree for this:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-sh" data-lang="sh"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;mkdir build-gcc295
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;cd build-gcc295
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;CC&lt;span style="color:#f92672"&gt;=&lt;/span&gt;gcc CXX&lt;span style="color:#f92672"&gt;=&lt;/span&gt;g++ ../configure --enable-debug
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;make
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;The compiler is particularly good at finding ambitious template code. Partial specialization, dependent names, and clever overloads can all expose old parser bugs or incomplete language support. Usually the least surprising spelling wins: name types explicitly, keep templates small, and avoid making overload resolution solve a riddle.&lt;/p&gt;
&lt;p&gt;One more trap is mixing C++ libraries. An object compiled against an incompatible &lt;code&gt;libstdc++&lt;/code&gt; is not made safe merely because the linker accepted it. I build the whole program and its local libraries with the same toolchain.&lt;/p&gt;
&lt;p&gt;I would rather write plain code than maintain compiler-specific branches. It is less exciting, but so is a build finishing successfully, and I have learned to appreciate that particular lack of excitement.&lt;/p&gt;</description></item></channel></rss>