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