tech-pkg archive

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

Re: Support GCC runtime



* On 2012-09-11 at 09:29 BST, Steven Drake wrote:

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

Fair enough, it works for us, but yes it's hardly clean :)

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

Great, yes please!

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

This would be a start, but we also need a package which only contains
libgcc, to avoid the:

  perl
  gcc-runtime (libgcc, libstdc++, ..)
  gcc
  perl

circular dependency, so that it'd look something like:

  perl
  gcc-runtime-c
  gcc-bootstrap

Thanks,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com


Home | Main Index | Thread Index | Old Index