Bug #8435
closedCan't build tcl/tk extensions after updating Debian/Ubuntu package
Description
I've recently upgraded my Ubuntu system to 13.04 and tcl8.5-dev and tk8.5-dev were updated as well (to versions 8.5.13-1ubuntu and 8.5.11-2ubuntu4 respectively).
Now I can't build Tcl/Tk Ruby extensions anymore. I was able to reproduce the problem with
ruby 2.0.0p195 (2013-05-14 revision 40734) [x86_64-linux] and
ruby 2.1.0dev (2013-05-21 trunk 40883) [x86_64-linux].
Looking at source:/ext/tk/extconf.rb@39974#L376 I see that extconf tries to parse tclConfig.sh and tkConfig.sh, which worked nice previously when those files were ln'ed to the actual configuration files. However, after the update they look like this on my platform:
$ cat /usr/lib/tclConfig.sh
#!/bin/sh
. /usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`/tclConfig.sh
$ cat /usr/lib/tkConfig.sh
#!/bin/sh
. /usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`/tkConfig.sh
So the setup fails:
...
Search tclConfig.sh and tkConfig.sh.....................
WARNING: found "/usr/lib/tclConfig.sh", but cannot find valid Tcl library for the tclConfig.sh. So, ignore it.
WARNING: found "/usr/lib/tkConfig.sh", but cannot find valid Tk library for the tkConfig.sh. So, ignore it.
..........
Fail to find [tclConfig.sh, tkConfig.sh]
...
Full 'ruby extconf.rb' output and mkmf.log are attached.
Files
Updated by romuloceccon (Rômulo Ceccon) over 11 years ago
Workaround is to specify actual location of tcl/tk files:
./configure --with-tclConfig-file=/usr/lib/x86_64-linux-gnu/tclConfig.sh --with-tkConfig-file=/usr/lib/x86_64-linux-gnu/tkConfig.sh
It looks like the change in the *.sh scripts intend to improve support for DEB_HOST_MULTIARCH. I don't know how prevalent the problem will be for other platforms, or what the policy is for Ruby regarding that kind of workaround.
Updated by zzak (zzak _) over 11 years ago
Seems like third party issue
Updated by hsbt (Hiroshi SHIBATA) over 11 years ago
- Category set to ext
- Assignee set to nagai (Hidetoshi Nagai)
- Target version set to 2.1.0
Updated by romuloceccon (Rômulo Ceccon) over 11 years ago
A possible fix:
--- a/ext/tk/extconf.rb 2013-01-10 05:47:20.000000000 -0200
+++ b/ext/tk/extconf.rb 2013-05-25 21:32:54.230020034 -0300
@@ -117,6 +117,11 @@
/64|universal/ =~ RUBY_PLATFORM
end
+def multiarch_supported?
- dpkg_arch =
which dpkg-architecture
.strip -
#{dpkg_arch} -qDEB_HOST_MULTIARCH
.strip unless dpkg_arch.empty?
+end
def check_tcltk_version(version)
return [nil, nil] unless version.kind_of? String
@@ -466,7 +471,14 @@
config_dir << RbConfig::CONFIG['libdir']
- ((maybe_64bit?)? ['lib64', 'lib']: ['lib']).each{|dir|
- if arch = multiarch_supported?
-
lib_dirs = ["lib/#{arch}", 'lib']
- elsif maybe_64bit?
-
lib_dirs = ['lib64', 'lib']
- else
-
lib_dirs = ['lib']
- end
- lib_dirs.each{|dir|
config_dir.concat [
File.join(RbConfig::CONFIG['exec_prefix'], dir),
File.join(RbConfig::CONFIG['prefix'], dir),
Updated by nobu (Nobuyoshi Nakada) over 11 years ago
romuloceccon (Romulo Ceccon) wrote:
+def multiarch_supported?
- dpkg_arch =
which dpkg-architecture
.strip#{dpkg_arch} -qDEB_HOST_MULTIARCH
.strip unless dpkg_arch.empty?
+end
`` returns a string, that is true value.
Possibly,
/\S/ =~ dpkg-architecture -qDEB_HOST_MULTIARCH
rescue false
?
Updated by romuloceccon (Rômulo Ceccon) over 11 years ago
The idea is that the method would also return the architecture as a string, but return false if dpkg-architecture is not available or is of an older version (DEB_HOST_MULTIARCH unsupported). So a more comprehensive approach could be:
def multiarch_supported?
cmd = `which dpkg-architecture 2>/dev/null`
return unless $?.success?
arch = `#{cmd.strip} -qDEB_HOST_MULTIARCH`
arch.strip if $?.success?
end
Updated by nagai (Hidetoshi Nagai) over 11 years ago
- Status changed from Open to Third Party's Issue
It depends on Ubuntu packages. The patch may be able to avoid the "current" problem,
but it cannot guarantee that it is available in the next version of Ubuntu.
If the policy of Ubuntu is changed, extconf.rb must check the Tcl/Tk package version of Ubuntu.
I think that it is not a good choice.
Although it may be troble, please use configure options.