[odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
Dave Johansen
davejohansen at gmail.com
Fri Jan 11 10:27:29 EST 2013
On Thu, Jan 10, 2013 at 7:58 AM, Boris Kolpackov
<boris at codesynthesis.com> wrote:
> Hi Dave,
>
> Dave Johansen <davejohansen at gmail.com> writes:
>
>> But like you mentioned previously, RHEL 5 and 6 only come with GCC 4.4,
>> so what do you recommend as the best way to do this?
>
> I think the best way to package ODB for RHEL 5 and 6 is to re-package
> the binary package that we provide. Again, this will be a "legacy"
> solution. For RHEL 7 and for Fedora that come with GCC 4.5 or later
> we can implement the nice and clean "from source" approach.
>
> I think using our binary package is better than trying to build and
> package both GCC and ODB from source for the following reasons:
>
> 1. Building and especially packaging a private copy of GCC won't
> be trivial.
>
> 2. We already take great care to build a portable package that
> can work on a wide range of Linux distributions. Might as
> well re-use this hard work.
>
> 3. We are planning to keep releasing this binary package for the
> foreseeable future.
>
> If you look inside, say, odb-X.Y.Z-x86_64-linux-gnu, you will see
> that it already resembles a Linux filesystem pretty closely. That
> is, the ODB compiler is in the bin/ sub-directory, configuration
> is in etc/, and so on.
>
> The only thing that doesn't quite fit is the x86_64-linux-gnu/
> sub-directory which contains the private copy of GCC. Now, while
> you can move doc/ and man/ sub-directories pretty much anywhere
> you want, bin/, etc/, and x86_64-linux-gnu/ are expected to be
> all at the same level: the ODB compiler uses the executable path
> (i.e., .../bin/odb) to construct the paths to the default options
> file (in etc/) and to the g++ executable (in x86_64-linux-gnu/).
>
> The good news is that it is possible to override the path to g++
> with the -x ODB compiler option. The bad news is that this option
> is not recognized in the default options file, which is where we
> could have conveniently put it if we were to move/rename
> x86_64-linux-gnu to something more suitable.
>
> So I went ahead and fixed this. If you would like to give it a try,
> the binary for the 2.2.0.a2 pre-release is here:
>
> http://codesynthesis.com/~boris/tmp/odb/odb-2.2.0.a2-x86_64-linux-gnu.tar.bz2
>
> And the rest of the pre-release is here:
>
> http://codesynthesis.com/download/odb/pre-release/
>
> Specifically, with this binary, we can do the following:
>
> 1. Rename x86_64-linux-gnu/ to, say, lib/odb/gcc/, so that it is installed
> in /usr/lib/odb/gcc.
>
> 2. Add the following option to etc/odb/default.options:
>
> -x /usr/lib/odb/gcc/bin/g++
>
> Other than that, the .spec file would just need to copy all the parts
> into the right places, and that's it.
>
> Now, that would only apply to packaging the ODB compiler. All the other
> packages (libodb, libodb-<db>, etc) would be built and packaged from
> source using the stock GCC that comes with RHEL.
>
> Boris
You're right about building gcc as part of building the ODB compiler
being a pain, but I think it's the best option in the long run. It
means that everything that is needed is contained in the source RPM
and can be viewed and changed in one location and then the binary RPM
regenerated as needed. It makes audits/inspections of the code/RPM
easier and means that everything can be done in one place instead of
grabbing pieces from several places and bundling them up. Basically, I
think it's more work up front but makes everything a lot easier in the
long run. Is there somewhere that I can get access to how you built
and packaged gcc for your binary releases of the compiler?
Thanks,
Dave
More information about the odb-users
mailing list