Your message dated Tue, 19 Apr 2011 20:49:36 -0700
with message-id <[email protected]>
and subject line Re: Bug#621500: override file for extension path
has caused the Debian Bug report #621500,
regarding gem2deb: Gems with external .so and LOAD_PATH issues
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
621500: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621500
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: gem2deb
Version: 0.2.1-1
Severity: important
Note this is a personally built gem2deb but that shouldn't be a factor here.
The yajl-ruby gem has yajl.rb and yajl.so
I think gem2deb is responsible for putting the extension into a
consistent place; however, since the names are the same I had to patch
my packaging to change the main yajl.rb from:
require 'yajl/yajl'
to
require 'yajl.so'
see
https://github.com/lbt/yajl-ruby/blob/debian/debian/patches/0001-debian-changes-0.8.1-1.patch
In gem2deb 0.1 it would install to:
/usr/lib/ruby/vendor_ruby/1.8/yajl.rb
/usr/lib/ruby/vendor_ruby/1.8/i486-linux/yajl.so
in 0.2 it installs to:
/usr/lib/ruby/vendor_ruby/yajl.rb
/usr/lib/ruby/vendor_ruby/1.8/i486-linux/yajl.so
Which wouldn't be a problem ... but that
$LOAD_PATH is ["/usr/local/lib/site_ruby/1.8",
"/usr/local/lib/site_ruby/1.8/i486-linux",
"/usr/local/lib/site_ruby/1.8/i386-linux", "/usr/local/lib/site_ruby",
"/usr/lib/ruby/vendor_ruby/1.8", "/usr/lib/ruby/vendor_ruby/1.8/i486-linux",
"/usr/lib/ruby/vendor_ruby", "/usr/lib/ruby/1.8",
"/usr/lib/ruby/1.8/i486-linux", "/usr/lib/ruby/1.8/i386-linux", "."]
Note that
/usr/lib/ruby/vendor_ruby/1.8
precedes
/usr/lib/ruby/vendor_ruby/1.8/i486-linux
but
/usr/lib/ruby/1.8
supercedes it
The result of which is that the initial 'require yajl' now pulls in
the yajl.so which succeeds but of course many methods are "just
missing". (This was not easy to find...)
It would be awfully nice if upstream could call the extension
yajl_ext.so but I wonder if it makes more sense to have all extension
PATH_LOAD entries follow all ruby PATH_LOAD entries by default.
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.37-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gem2deb depends on:
ii build-essential 11.5 Informational list of build-essent
ii debhelper 8.0.0 helper programs for debian/rules
ii devscripts 2.10.69+squeeze1 scripts to make the life of a Debi
ii perl 5.10.1-17 Larry Wall's Practical Extraction
ii ruby1.8 1.8.7.302-2 Interpreter of object-oriented scr
ii ruby1.8-dev 1.8.7.302-2 Header files for compiling extensi
ii ruby1.9.1 1.9.2.0-2 Interpreter of object-oriented scr
ii ruby1.9.1-dev 1.9.2.0-2 Header files for compiling extensi
ii rubygems1.8 1.3.7-3 package management framework for R
gem2deb recommends no packages.
gem2deb suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Bryan McLellan escreveu isso aí:
> I hacked a config file in to specify an override file for where to
> place the extension. I'm not sure if there are any other packages with
> this issue or not, so it is hard to gauge the appropriate fix. With
> this change to gem2deb, adding a debian/extension_path.overrides file
> that contains 'yajl' produces a good yajl-ruby deb using gem2deb for
> me.
>
> Note that somewhere along the line the vendor_ruby/VERSION/ARCH
> directory included in the $LOAD_PATH for i386 changed, which caused me
> a little trouble debugging.
>
> /usr/lib/ruby/vendor_ruby/1.8/i486-linux (lucid)
> /usr/lib/ruby/vendor_ruby/1.8/i686-linux (maverick)
I dont't think we should hack gem2deb to cope with a broken upstream
buildsystem:
terceiro@morere:/tmp/yajl-ruby/ext/yajl (master)$ make install DESTDIR=/tmp/bli
mkdir -p /tmp/bli/usr/local/lib/site_ruby/1.8/i486-linux
/usr/bin/install -c -m 0755 yajl.so
/tmp/bli/usr/local/lib/site_ruby/1.8/i486-linux
terceiro@morere:/tmp/yajl-ruby/ext/yajl (master)$ find /tmp/bli/
/tmp/bli/
/tmp/bli/usr
/tmp/bli/usr/local
/tmp/bli/usr/local/lib
/tmp/bli/usr/local/lib/site_ruby
/tmp/bli/usr/local/lib/site_ruby/1.8
/tmp/bli/usr/local/lib/site_ruby/1.8/i486-linux
/tmp/bli/usr/local/lib/site_ruby/1.8/i486-linux/yajl.so
so yajl.so is supposed to be in a directory called 'yajl', but
upstream's `make install` does not put it there.
It only works with rubygems because rubygems does not call make install,
it just add whatever paths the gem author says to the $LOAD_PATH.
mkmf actually documents the correct way of putting extentions in
subdirectories:
# Generates the Makefile for your extension, passing along any options and
# preprocessor constants that you may have generated through other methods.
#
# The +target+ name should correspond the name of the global function name
# defined within your C extension, minus the 'Init_'. For example, if your
# C extension is defined as 'Init_foo', then your target would simply be 'foo'.
#
# If any '/' characters are present in the target name, only the last name
# is interpreted as the target name, and the rest are considered toplevel
# directory names, and the generated Makefile will be altered accordingly to
# follow that directory structure.
#
# For example, if you pass 'test/foo' as a target name, your extension will
# be installed under the 'test' directory. This means that in order to
# load the file within a Ruby program later, that directory structure will
# have to be followed, e.g. "require 'test/foo'".
#
# The +srcprefix+ should be used when your source files are not in the same
# directory as your build script. This will not only eliminate the need for
# you to manually copy the source files into the same directory as your build
# script, but it also sets the proper +target_prefix+ in the generated
# Makefile.
#
# Setting the +target_prefix+ will, in turn, install the generated binary in
# a directory under your Config::CONFIG['sitearchdir'] that mimics your local
# filesystem when you run 'make install'.
#
# For example, given the following file tree:
#
# ext/
# extconf.rb
# test/
# foo.c
#
# And given the following code:
#
# create_makefile('test/foo', 'test')
#
# That will set the +target_prefix+ in the generated Makefile to 'test'. That,
# in turn, will create the following file tree when installed via the
# 'make install' command:
#
# /path/to/ruby/sitearchdir/test/foo.so
#
# It is recommended that you use this approach to generate your makefiles,
# instead of copying files around manually, because some third party
# libraries may depend on the +target_prefix+ being set properly.
#
# The +srcprefix+ argument can be used to override the default source
# directory, i.e. the current directory . It is included as part of the VPATH
# and added to the list of INCFLAGS.
#
def create_makefile(target, srcprefix = nil)
[...]
Actually, with the attached patch, yajl-ruby installs to correct place:
terceiro@morere:/tmp/yajl-ruby/ext (master)$ make install DESTDIR=/tmp/flock
mkdir -p /tmp/flock/usr/local/lib/site_ruby/1.8/i486-linux/yajl
/usr/bin/install -c -m 0755 yajl.so
/tmp/flock/usr/local/lib/site_ruby/1.8/i486-linux/yajl
terceiro@morere:/tmp/yajl-ruby/ext (master)$ find /tmp/flock/
/tmp/flock/
/tmp/flock/usr
/tmp/flock/usr/local
/tmp/flock/usr/local/lib
/tmp/flock/usr/local/lib/site_ruby
/tmp/flock/usr/local/lib/site_ruby/1.8
/tmp/flock/usr/local/lib/site_ruby/1.8/i486-linux
/tmp/flock/usr/local/lib/site_ruby/1.8/i486-linux/yajl
/tmp/flock/usr/local/lib/site_ruby/1.8/i486-linux/yajl/yajl.so
terceiro@morere:/tmp/yajl-ruby/ext (master)$
--
Antonio Terceiro <[email protected]>
http://softwarelivre.org/terceiro
From eb403408c2e39cb77d635576e7add012430173be Mon Sep 17 00:00:00 2001
From: Antonio Terceiro <[email protected]>
Date: Tue, 19 Apr 2011 20:45:19 -0700
Subject: [PATCH] Fix native extention installation path
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621500
---
ext/extconf.rb | 8 ++++++++
ext/yajl/extconf.rb | 8 --------
2 files changed, 8 insertions(+), 8 deletions(-)
create mode 100644 ext/extconf.rb
delete mode 100644 ext/yajl/extconf.rb
diff --git a/ext/extconf.rb b/ext/extconf.rb
new file mode 100644
index 0000000..bc1ba81
--- /dev/null
+++ b/ext/extconf.rb
@@ -0,0 +1,8 @@
+# encoding: UTF-8
+require 'mkmf'
+require 'rbconfig'
+
+$CFLAGS << ' -Wall -funroll-loops'
+$CFLAGS << ' -Wextra -O0 -ggdb3' if ENV['DEBUG']
+
+create_makefile("yajl/yajl", "yajl")
diff --git a/ext/yajl/extconf.rb b/ext/yajl/extconf.rb
deleted file mode 100644
index 9db2689..0000000
--- a/ext/yajl/extconf.rb
+++ /dev/null
@@ -1,8 +0,0 @@
-# encoding: UTF-8
-require 'mkmf'
-require 'rbconfig'
-
-$CFLAGS << ' -Wall -funroll-loops'
-$CFLAGS << ' -Wextra -O0 -ggdb3' if ENV['DEBUG']
-
-create_makefile("yajl")
--
1.7.4.1
signature.asc
Description: Digital signature
--- End Message ---
