tech-pkg archive

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

Re: Avoiding cycles in the dependency tree



* On 2013-02-24 at 21:44 GMT, Thomas Cort wrote:

> Background: Minix has no compilers in the base system. The 2 compilers
> (gcc and clang) are built with pkgsrc. All minix systems come
> prebootstraped (i.e. the install CD installs pkg_install, pkgin,
> clang, etc). To use pkgsrc beyond just binary packages with pkgin,
> users checkout our patched version of the pkgsrc tree (from
> git.minix3.org:pkgsrc), they install gcc44 with pkgin, use our default
> mk.conf ( 
> http://git.minix3.org/?p=pkgsrc.git;a=blob;f=minix/mk.conf.minix;h=7c236edefa0a906d3cd3a2aaff5be63e237562bc;hb=HEAD
> ), and they're ready to go.
> 
> Issue #1: We get cyclic dependency issues with gcc. I assume this is
> because gcc requires gcc to build. Is there an existing workaround for
> this or any advice on how to approach a fix?

We have a very similar setup in SmartOS land - the platform does not
contain a compiler, and we provide it from pkgsrc.  We do not see
circular issues that you do, so hopefully that's at least a useful
datapoint that you can start to look at your environment setup to see
where the issue lies, rather than it being something unsupported by
pkgsrc.

There is quite a lot of stuff in your mk.conf which is at best not
necessary, and worst could be harmful, so I'd suggest starting with a
very basic one as produced by ./bootstrap and going from there.

Certainly you shouldn't need to define AR, LD, CC - COMPILER_TYPE is
unused in pkgsrc, etc.

> Issue #2: pbulk doesn't really work because it blows away /usr/pkg
> (where the compilers live) when it tries to build packages. We've
> tried installing the toolchain into another directory (/usr/pkg.sav/),
> but libtool and other tools sometimes pick up stuff in that directory.
> Any advice on this front? Maybe add gcc to the binary bootstrap kit
> for Minix?

What I do is bootstrap a pbulk environment into /opt/pbulk which
contains gcc47, pbulk, and a few useful utilities for package
development (pkgdiff, git, etc).  I then use the gcc from there via
GCCBASE=/opt/pbulk/gcc47 in the main /opt/pkg build.

Finally, when I produce a bootstrap kit of the live /opt/pkg prefix
for users, I remove GCCBASE and users are able to 'pkgin in gcc47' and
start building packages with the native /opt/pkg compiler.

BTW, it'd be great to get any patches you have into mainline pkgsrc,
if they are appropriate.

Thanks,

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


Home | Main Index | Thread Index | Old Index