Puppet 3.0 fails install on Solaris 10 w/ ruby 1.8.7

[Forrie]

There's a problem installing puppet on Solaris 10 -- in this situation, we aren't really doing anything with puppet there.

The version we're using is:

ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-solaris2.9]

Here's the first error:

# gem update puppet

Updating installed gems

Updating puppet

Building native extensions.  This could take a while...

ERROR:  Error installing puppet:

        ERROR: Failed to build gem native extension.

        /opt/csw/bin/ruby18 extconf.rb

extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)

        from extconf.rb:1

Gem files will remain installed in /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5 for inspection.

Results logged to /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5/ext/json/ext/generator/gem_make.out

Nothing to update

So I decided to uninstall the old version and try again:

# gem uninstall puppet

Remove executables:

        filebucket, pi, puppet, puppetdoc, ralsh, puppetca, puppetd, puppetmasterd, puppetqd, puppetrun

in addition to the gem? [Yn]  y

Removing filebucket

Removing pi

Removing puppet

Removing puppetdoc

Removing ralsh

Removing puppetca

Removing puppetd

Removing puppetmasterd

Removing puppetqd

Removing puppetrun

Successfully uninstalled puppet-2.7.18

Now a fresh install:

 

# gem install puppet

Building native extensions.  This could take a while...

ERROR:  Error installing puppet:

        ERROR: Failed to build gem native extension.

        /opt/csw/bin/ruby18 extconf.rb

extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)

        from extconf.rb:1

Gem files will remain installed in /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5 for inspection.

Results logged to /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5/ext/json/ext/generator/gem_make.out

 The content of this last file is the same as the above error message:

extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)

        from extconf.rb:1

Anyone know what the issue is?

Thanks. 

[Matthaus Owens]

The puppet 3 gem requires hiera, whose latest version requires json,
which can be either json (a c extension), or json_pure (a ruby
implementation). If it is the c extension, make and gcc are required
to build the c components. The mkmf error usually indicates that make
and/or gcc are unavailable.

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/6bxXifJJK1AJ.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.



--
Matthaus Owens
Release Manager, Puppet Labs

[Justin Stoller]

On Mon, Oct 1, 2012 at 4:28 PM, Matthaus Owens <matt...@puppetlabs.com> wrote:
> The puppet 3 gem requires hiera, whose latest version requires json,
> which can be either json (a c extension), or json_pure (a ruby
> implementation). If it is the c extension, make and gcc are required
> to build the c components. The mkmf error usually indicates that make
> and/or gcc are unavailable.

The development headers for ruby are also required, I believe
ruby18-dev will pull in the gnu compiler utils as well if you install
it:
http://www.opencsw.org/packages/CSWruby18-dev/
http://www.opencsw.org/packages/CSWruby18-gcc4/

This is the same way most linux distros package ruby, so issues you
see around compiling native extensions for linux should be equally
helpful for you.

Or you can install the pre-compiled json gem:
http://www.opencsw.org/packages/CSWrb18-json-1-5-3/


- Justin

[Forrie]

I solved the ruby18_dev dependency. However, when I go to compile, I
get this error:

# gem install puppet
Building native extensions. This could take a while...
ERROR: Error installing puppet:
ERROR: Failed to build gem native extension.

/opt/csw/bin/ruby18 extconf.rb

creating Makefile

make
/opt/SUNWspro/bin/cc -I. -I/opt/csw/lib/ruby/1.8/i386-solaris2.9 -I/
opt/csw/lib/ruby/1.8/i386-solaris2.9 -I. -DJSON_GENERATOR -I/opt/csw/
include -D_FILE_OFFSET_BITS=64 -KPIC -xO3 -m32 -xarch=386 -KPIC -
O3 -c generator.c
make: /opt/SUNWspro/bin/cc: Command not found
make: *** [generator.o] Error 127

Gem files will remain installed in /opt/csw/lib/ruby/gems/1.8/gems/
json-1.7.5 for inspection.
Results logged to /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5/ext/json/
ext/generator/gem_make.out

Interesting as I haven't used that in a long time and it's not
installed here. This variable is not set anywhere in the environment
that I can tell. Equally, when I manually set CC=/opt/csw/bin/gcc
(and export it) the build does not honor that.

Interestingly, when I do a "find" I can see this mentioned in the /opt/
csw/lib/ruby structure:

# find . -type f -exec grep SUNWspro {} \;
CONFIG["configure_args"] = " '--prefix=/opt/csw' '--exec_prefix=/opt/
csw' '--bindir=/opt/csw/bin' '--sbindir=/opt/csw/sbin' '--libexecdir=/
opt/csw/libexec' '--datadir=/opt/csw/share' '--sysconfdir=/opt/csw/
etc' '--sharedstatedir=/opt/csw/share' '--localstatedir=/opt/csw/var'
'--libdir=/opt/csw/lib' '--infodir=/opt/csw/share/info' '--includedir=/
opt/csw/include' '--mandir=/opt/csw/share/man' '--enable-pthread' '--
enable-shared' '--with-tcl-dir=/opt/csw' '--with-tk-dir=/opt/csw' '--
with-dbm-dir=/opt/csw/bdb48' '--with-gdbm-dir=/opt/csw' '--with-iconv-
dir=/opt/csw' '--with-openssl-dir=/opt/csw' '--with-readline-dir=/opt/
csw' '--with-zlib-dir=/opt/csw' '--program-suffix=18' 'CC=/opt/
SUNWspro/bin/cc' 'CFLAGS=-xO3 -m32 -xarch=386' 'LDFLAGS=-L/opt/csw/
lib' 'CPPFLAGS=-I/opt/csw/include'"
CONFIG["CPP"] = "/opt/SUNWspro/bin/cc -E"
CONFIG["CC"] = "/opt/SUNWspro/bin/cc"
/opt/SUNWspro/bin/cc -I. -I/opt/csw/lib/ruby/1.8/i386-solaris2.9 -I/
opt/csw/lib/ruby/1.8/i386-solaris2.9 -I. -DJSON_GENERATOR -I/opt/csw/
include -D_FILE_OFFSET_BITS=64 -KPIC -xO3 -m32 -xarch=386 -KPIC -
O3 -c generator.c
make: /opt/SUNWspro/bin/cc: Command not found
CC = /opt/SUNWspro/bin/cc


We have solstudio2.2 installed -- so I put a symlink in /opt pointing
SUNWspro -> solstudio2.2 and it seems happy.

I'm just putting this out here in case someone else gets bitten by
it :-)

[Phips]

On Tuesday, October 2, 2012 12:18:46 AM UTC+1, Forrie wrote:

There's a problem installing puppet on Solaris 10 -- in this situation, we aren't really doing anything with puppet there.

Hi,

I see you're using CSW Ruby anyway - I've just released CSWpuppet3, should be available in a day or so. It'll save you all this broken gem installing effort ;)

[Alex Harvey]

On Tuesday, October 2, 2012 9:28:09 AM UTC+10, Matthaus Litteken wrote:

The puppet 3 gem requires hiera, whose latest version requires json,
which can be either json (a c extension), or json_pure (a ruby
implementation). If it is the c extension, make and gcc are required
to build the c components. The mkmf error usually indicates that make
and/or gcc are unavailable.

I am also encountering this issue but using json_pure doesn't help -

# gem install --local json_pure-1.7.5.gem hiera-1.1.1.gem puppet-3.0.1.gem
Successfully installed json_pure-1.7.5
ERROR:  While executing gem ... (Gem::DependencyError)
    Unable to resolve dependencies: hiera requires json (>= 0)

Meanwhile, a requirement for there to be a C compiler on every host seems to be insane.

[jcbollinger]

The requirement for a local C compiler is pretty much a function of the choice to use gems in general.  In principle, any gem may contain a native extension that needs to be built, so gem-dependent systems need to have the requisite development tools.

I avoid 'gem' on principle, relying instead on hosts' native package managers.  It is a bad idea to mix multiple package managers with overlapping areas of responsibility, and on systems that have a system-wide package manager, that precludes using any other.


John

[Alex Harvey]

On Tuesday, December 18, 2012 2:02:28 AM UTC+11, jcbollinger wrote:

The requirement for a local C compiler is pretty much a function of the choice to use gems in general.  In principle, any gem may contain a native extension that needs to be built, so gem-dependent systems need to have the requisite development tools.

I avoid 'gem' on principle, relying instead on hosts' native package managers.  It is a bad idea to mix multiple package managers with overlapping areas of responsibility, and on systems that have a system-wide package manager, that precludes using any other.

Gems are convenient at sites where many different native package managers are in use.  A site that has RedHat, Ubuntu, Solaris 10, Solaris 11, AIX & HP-UX will have six different native package managers to work with and rolling puppet, hiera & facter into all of these formats is time consuming compared to using gems.

Since it appears the intention was to allow hiera to depend on either json or json_pure (which unfortunately appears to be impossible in a gemspec file) I have raised a bug against hiera -
http://projects.puppetlabs.com/issues/18214

Hopefully we can change this dependency as it effectively makes it impossible to install puppet as a gem.

[jcbollinger]

On Wednesday, December 19, 2012 12:06:12 AM UTC-6, Alex Harvey wrote:

On Tuesday, December 18, 2012 2:02:28 AM UTC+11, jcbollinger wrote:

[...]

I avoid 'gem' on principle, relying instead on hosts' native package managers.  It is a bad idea to mix multiple package managers with overlapping areas of responsibility, and on systems that have a system-wide package manager, that precludes using any other.

Gems are convenient at sites where many different native package managers are in use.  A site that has RedHat, Ubuntu, Solaris 10, Solaris 11, AIX & HP-UX will have six different native package managers to work with and rolling puppet, hiera & facter into all of these formats is time consuming compared to using gems.

The time spent up front to do the job right often produces much more time saved later on (indeed, that's a large component of "right").  In any case, PuppetLabs provides pre-built packages for a lot of different package management systems, so for the Puppet stack in particular, the up-front time you would need to invest is less than you may suppose.


John

[Philip Brown]

On Wednesday, December 19, 2012 6:14:48 AM UTC-8, jcbollinger wrote:

The time spent up front to do the job right often produces much more time saved later on (indeed, that's a large component of "right").  In any case, PuppetLabs provides pre-built packages for a lot of different package management systems, so for the Puppet stack in particular, the up-front time you would need to invest is less than you may suppose.

That being said, since puppet IS ruby code, "a large component of 'right'" could reasonably be defined as "there should be a functional ruby gem for it"!
 

[Alex Harvey]

On Thursday, December 20, 2012 4:49:33 AM UTC+11, Philip Brown wrote:

That being said, since puppet IS ruby code, "a large component of 'right'" could reasonably be defined as "there should be a functional ruby gem for it"!

And if that doesn't work for you there are two other considerations -

- some people need to maintain their own patches for facter & puppet.  At this point puppet labs has accepted all of my patches upstream but sooner or later I expect to encounter a situation where I need to maintain patches of my own.

- having a single package manager for the puppet stack means when I want to see my installed puppet version I only need to know one command - gem list.  So it's easier than having to know the commands for six package managers.  And my installed puppet code is always in /usr/local/lib/ruby/gems/1.8/gems no matter what platform I'm on. 

Now the best solution would be for every Unix to just standardise on a single package management system.  Debian's one is quite good.  Now, there's an ideal world for you. :)