tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Support GCC runtime



On Fri, 7 Sep 2012, Jonathan Perkin wrote:
> * On 2012-07-25 at 10:27 BST, Steven Drake wrote:
> 
> > On Tue, 24 Jul 2012, Jonathan Perkin wrote:
> > 
> > > Proposal
> > > ========
> > > 
> > >   We split gcc47 into separate -compiler and -runtime packages, and
> > >   retain a meta package for gcc47 which includes both.  Packages can
> > >   now depend upon just the -runtime package for _GCC_USE_SHLIB.
> > > 
> > > [...] 
> > > 
> > > Code
> > > ====
> > I haven't had a look at it yet and I'll get email you again after I've
> > had a look at it.

> Do you have any updates on this?  I'd really like to get this stuff in
> for 2012Q3 as we depend upon it, even if it's sub-optimal.

Sorry I haven't got back to you sooner as I've been working on the problem.

As far as your gcc47-compiler & gcc47-runtime packages goes I'm totally
against committing them to the tree as there are so many problems with them
(I won't go in to detail because of the number) that it would not only
cause a significant number of build problems on different OS's but it 
would make maintenance a nightmare! 

Having siad that I've come up with a much much simpler and less disruptive
approach (if a little bit hackish)  for having a package that contains just
the support libraries that I am happen to commit to the tree straight away 
f you want?

As for my idea as to how to get around the USE_LIBTOOL/USE_GCC_RUNTIME stuff
I haven't had time to dig into that yet.

> One additional issue I've ran into is a circular dependency between
> gcc47-runtime and perl, as perl is required for the g++ build.  My
> initial thought to fix this would be to split the runtime package
> further into runtime-c, runtime-c++ etc.  This would increase overall
> build times, but would reduce dependency sizes and build times for
> packages which only require libgcc.

I think a better long term solution for that problem and the circular
dependency problem with USE_PKGSRC_GCC is to have a gcc-bootstrap package
that builds just the c complier.

-- 
Steven


Home | Main Index | Thread Index | Old Index