Zlib Failure when installing some gems on OpenBSD powerpc #649

Closed
jeremyevans opened this Issue Jan 5, 2011 · 3 comments

Projects

None yet

3 participants

@jeremyevans
Rubinius member

Here's the command and traceback. There isn't a problem with the gem files, since they install correctly on amd64 and i386. My guess is some issue with FFI on the powerpc architecture, since rubinius implements Zlib with FFI, while MRI uses a C extension and doesn't have this issue on powerpc.

If you'd like more information or access to an OpenBSD powerpc box for testing, let me know and I'll see if I can arrange it.

/usr/local/bin/rbx -S gem install --local --no-rdoc --no-ri --no-force --verbose --backtrace --user-install /usr/ports/pobj/extlib-0.9.15-rbx/extlib-0.9.15.gem
ERROR: While executing gem ... (Zlib::GzipFile::Error)
invalid compressed data -- length error
/usr/local/lib/rubinius/1.1/lib/zlib.rb:1050:in read'
/usr/local/lib/rubinius/1.1/lib/rubygems/specification.rb:518:in
normalize_yaml_input'
/usr/local/lib/rubinius/1.1/lib/rubygems/specification.rb:479:in from_yaml'
/usr/local/lib/rubinius/1.1/lib/rubygems/package/tar_input.rb:183:in
load_gemspec'
/usr/local/lib/rubinius/1.1/lib/rubygems/package/tar_input.rb:51:in initialize'
/usr/local/lib/rubinius/1.1/lib/rubygems/package/tar_reader.rb:64:in
each'
/usr/local/lib/rubinius/1.1/lib/rubygems/package/tar_input.rb:51:in initialize'
/usr/local/lib/rubinius/1.1/lib/rubygems/package/tar_reader.rb:64:in
each'
kernel/common/kernel.rb:292:in loop'
/usr/local/lib/rubinius/1.1/lib/rubygems/package/tar_reader.rb:55:in
each'
/usr/local/lib/rubinius/1.1/lib/rubygems/package/tar_input.rb:32:in initialize'
/usr/local/lib/rubinius/1.1/lib/rubygems/package/tar_input.rb:17:in
open'
/usr/local/lib/rubinius/1.1/lib/rubygems/package.rb:58:in open'
/usr/local/lib/rubinius/1.1/lib/rubygems/format.rb:63:in
from_io'
/usr/local/lib/rubinius/1.1/lib/rubygems/format.rb:51:in from_file_by_path'
kernel/common/io.rb:262:in
open'
kernel/common/kernel.rb:221:in open'
/usr/local/lib/rubinius/1.1/lib/rubygems/format.rb:50:in
from_file_by_path'
/usr/local/lib/rubinius/1.1/lib/rubygems/dependency_installer.rb:194:in find_spec_by_name_and_version'
kernel/bootstrap/array.rb:66:in
each'
/usr/local/lib/rubinius/1.1/lib/rubygems/dependency_installer.rb:191:in find_spec_by_name_and_version'
/usr/local/lib/rubinius/1.1/lib/rubygems/dependency_installer.rb:237:in
install'
/usr/local/lib/rubinius/1.1/lib/rubygems/commands/install_command.rb:119:in execute'
kernel/bootstrap/array.rb:66:in
each'
/usr/local/lib/rubinius/1.1/lib/rubygems/commands/install_command.rb:116:in execute'
/usr/local/lib/rubinius/1.1/lib/rubygems/command.rb:270:in
invoke'
/usr/local/lib/rubinius/1.1/lib/rubygems/command_manager.rb:134:in process_args'
/usr/local/lib/rubinius/1.1/lib/rubygems/command_manager.rb:104:in
run'
/usr/local/lib/rubinius/1.1/lib/rubygems/gem_runner.rb:63:in run'
/usr/local/lib/rubinius/1.1/lib/bin/gem.rb:21:in
script'
kernel/delta/codeloader.rb:67:in load_script'
kernel/delta/codeloader.rb:91:in
load_script'
kernel/loader.rb:494:in script'
kernel/loader.rb:591:in
main'
kernel/loader.rb:630:in main'
kernel/loader.rb:641:in
script'

@jeremyevans
Rubinius member

After more digging, this is caused by Rubinius is using ulong as the ffi type for the total_in and total_out struct zstream members, and on OpenBSD, those members are defined as off_t, which is long long on powerpc. I'll patch this locally in the OpenBSD port, but I'll leave this open so you can decide how best to fix it.

@evanphx
Rubinius member

Brian and I brainstormed on this issue and have decided that the FFI struct preprocessor should, when the type is :int, :uint, :long, or :ulong, detect the true integer byte width and change the declared type to one that matches the signness and width.

This may not happen for 1.2.1 as we're slightly worried about it destabalizing other platforms, so the fix may have to wait.

@dbussink
Rubinius member

Since we've switched to MRI's zlib in 9aa6a37 and you stated that it wasn't a problem in MRI, I'm closing this issue. If it's still a problem, please let us know.

@dbussink dbussink closed this Jul 8, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment