Bug #1991: ruby should use twolevel namespace on OS X

• Status: Rejected
• Assignee: -
• Target version: 1.9.2
• ruby -v: darwin9.8.0

[hramrach (Michal Suchanek)]

=begin
Details:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/344658

Note: the patch is taken from a package that changes more than the namespace

• change namespace to twolevel
• add -Wl in front of linker flags to allow building extensions with libtool
• change the library name from libruby to libruby1.8 to prevent clashes with libruby1.9 (or something like that)

libruby is not explicitly linked twolevel because it should be the default on recent OS X and it does not need other special flags to work with twolevel namespace.
=end

[shyouhei (Shyouhei Urabe)]

=begin
Remember, 1.8.6 was released in May 2007, which is before-Leopard ara. As far as I know there was no problems on flat namespaces then.

I'm not against to abandon flat namespace for future ruby, but for old ones like 1.8.6, I am afraid such drastic change would break other extension libraries that depends on flatness of C namespaces.
=end

[hramrach (Michal Suchanek)]

=begin
2009/8/24 Shyouhei Urabe [e-mail]:

Issue #1991 has been updated by Shyouhei Urabe.

Remember, 1.8.6 was released in May 2007, which is before-Leopard ara.  As far as I know there was no problems on flat namespaces then.

Sorry, I don't know what leopard stands for. It's hard enough to
remember the numbers.

Either way twolevel namespace is available for quite some time on OS
X. According to ld(1) man page flat namespace was the default only on
10.0 and ever since twolevel should be available as it is the default.

However, since 10.3 it is possible to use dynamic lookup for libraries
which means that extensions can be built even with undefined symbols.
Previously you had to link dynamic object properly so that all symbols
are defined which might have prevented some sloppy extensions from
building.

iirc I was building twolevel on 10.2 as well which required that the
extensions were built properly or failed rather than installing and
failing to load.

Thanks

Michal

=end

[hramrach (Michal Suchanek)]

=begin
2009/8/24 Michal Suchanek [e-mail]:

2009/8/24 Shyouhei Urabe [e-mail]:

Issue #1991 has been updated by Shyouhei Urabe.

Remember, 1.8.6 was released in May 2007, which is before-Leopard ara.  As far as I know there was no problems on flat namespaces then.

Sorry, I did not make this clear the first time. The flat namespace
was always as limited as it is now. When two extensions use a library
of the same name but from different place (directly or through a
different library) than in flat namespace only one of the libraries is
loaded and which one depends on the order in which the extensions are
loaded.

In twolevel namespace every extension gets the library with which it was linked.

Then if you install an updated library in /usr/local or /opt or
whatever and build one extension against that library and one
extension against a system framework which uses the ancient system
libraries both still work.

Sorry, I don't know what leopard stands for. It's hard enough to
remember the numbers.

Either way twolevel namespace is available for quite some time on OS
X.  According to ld(1) man page flat namespace was the default only on
10.0 and ever since twolevel should be available as it is the default.

However, since 10.3 it is possible to use dynamic lookup for libraries
which means that extensions can be built even with undefined symbols.
Previously you had to link dynamic object properly so that all symbols
are defined which might have prevented some sloppy extensions from
building.

iirc I was building twolevel on 10.2 as well which required that the
extensions were built properly or failed rather than installing and
failing to load.

Thanks

Michal

=end

[shyouhei (Shyouhei Urabe)]

=begin
If -flat_namespace was the default for linking, we could safely omit that and we were all happy. There were reasons for that explicit option (back when OS X was 10.1 -- the time of that flag addition). As you know, when you compile ruby you first make miniruby, create bundles, then make ruby binary. Those -undefined suppress -flat_namespaces options are required for bundles because when they are compiled libruby.so is not yet installed. There was no -undefined dynamic_lookup option then.

Anyway as time went by, I think it's OK for 1.8.8 to move to -twolevel_namespace. What I worry is that 1.8.6 already has tons of third party extensions that has been compiled with -flat_namespace. Some of them might rely on the flatness of function namespace. For instance, Failmalloc ( http://www.nongnu.org/failmalloc/ ) sprung to my mind.
=end

[hramrach (Michal Suchanek)]

=begin
2009/8/24 Shyouhei Urabe [e-mail]:

Issue #1991 has been updated by Shyouhei Urabe.

If -flat_namespace was the default for linking, we could safely omit that and we were all happy.  There were reasons for that explicit option (back when OS X was 10.1 -- the time of that flag addition).  As you know, when you compile ruby you first make miniruby, create bundles, then make ruby binary.  Those -undefined suppress -flat_namespaces options are required for bundles because when they are compiled libruby.so is not yet installed.  There was no -undefined dynamic_lookup option then.

Anyway as time went by,  I think it's OK for 1.8.8 to move to -twolevel_namespace.  What I worry is that 1.8.6 already has tons of third party extensions that has been compiled with -flat_namespace.  Some of them might rely on the flatness of function namespace.  For instance, Failmalloc ( http://www.nongnu.org/failmalloc/ ) sprung to my mind.

According to their web site failmalloc relies on glibc (and LD_PRELOAD
is probably a feature of GNU ld which would not work on OS X). Sure,
there could be some very low level libraries that break.

On the other hand, some common and high-level libraries unexpectedly
break because of flat namespace.

=end

[shyouhei (Shyouhei Urabe)]

=begin
I once heared there is a Mac version of Failmalloc (sorry for lacking a pointer). At least there is DYLD_INSERT_LIBRARIES which is the counterpart of LD_PRELOAD.

It seems moving to twolevel namespaces has both merits and demerits. Perhaps I may be repeating myself but I just prefer persistent behavior for old versions like 1.8.6, because compatibility breakages are simply unallowable. I'm not against to move for 1.8.8.
=end

[nobu (Nobuyoshi Nakada)]

=begin
Hi,

At Mon, 24 Aug 2009 20:15:07 +0900,
Michal Suchanek wrote in [ruby-core:25086]:

Note: the patch is taken from a package that changes more than the namespace

And other changes? Don't mix different chnages.

• change namespace to twolevel

Pending.

• add -Wl in front of linker flags to allow building extensions with libtool

Applied to trunk.

• change the library name from libruby to libruby1.8 to prevent clashes with libruby1.9 (or something like that)

Reject. 1.9 uses libruby.1.9.1.dylib already, no needs to
change 1.8.

--
Nobu Nakada

=end

[hramrach (Michal Suchanek)]

=begin
2009/8/24 Nobuyoshi Nakada [e-mail]:

Hi,

At Mon, 24 Aug 2009 20:15:07 +0900,
Michal Suchanek wrote in [ruby-core:25086]:

Note: the patch is taken from a package that changes more than the namespace

And other changes?  Don't mix different chnages.

• change namespace to twolevel

Pending.

• add -Wl in front of linker flags to allow building extensions with libtool

Applied to trunk.

Thanks for looking into this.

• change the library name from libruby to libruby1.8 to prevent clashes with libruby1.9 (or something like that)

Reject.  1.9 uses libruby.1.9.1.dylib already, no needs to
change 1.8.

It should not affect complete ruby installations but it helps packaged
installations where multiple versions of the library coexist (such as
1.6 and 1.8). It allows installing the libruby link (and headers)
pointing to one of the libraries and still use executables linked with
both libraries.

When 1.8 uses libruby (without version in name) as the soname it is
impossible to install binaries linked with ruby 1.8 along with
development files for another ruby version, be it 1.6 or 1.9.

Thanks

Michal

=end

[shyouhei (Shyouhei Urabe)]

=begin
Michal Suchanek wrote:

• change the library name from libruby to libruby1.8 to prevent clashes with libruby1.9 (or something like that)
  Reject. 1.9 uses libruby.1.9.1.dylib already, no needs to
  change 1.8.

It should not affect complete ruby installations but it helps packaged
installations where multiple versions of the library coexist (such as
1.6 and 1.8). It allows installing the libruby link (and headers)
pointing to one of the libraries and still use executables linked with
both libraries.

When 1.8 uses libruby (without version in name) as the soname it is
impossible to install binaries linked with ruby 1.8 along with
development files for another ruby version, be it 1.6 or 1.9.

Don't wake a sleeping dog. 1.6 has been abandoned for at least 6 years.

Attachment: signature.asc
Attachment: signature.asc
Attachment: signature.asc
=end

[hramrach (Michal Suchanek)]

=begin
2009/8/27 Urabe Shyouhei [e-mail]:

Michal Suchanek wrote:

• change the library name from libruby to libruby1.8 to prevent clashes with libruby1.9 (or something like that)
  Reject.  1.9 uses libruby.1.9.1.dylib already, no needs to
  change 1.8.

It should not affect complete ruby installations but it helps packaged
installations where multiple versions of the library coexist (such as
1.6 and 1.8). It allows installing the libruby link (and headers)
pointing to one of the libraries and still use executables linked with
both libraries.

When 1.8 uses libruby (without version in name) as the soname it is
impossible to install binaries linked with ruby 1.8 along with
development files for another ruby version, be it 1.6 or 1.9.

Don't wake a sleeping dog.  1.6 has been abandoned for at least 6 years.

It's not like the situation with 1.8 vs 1.9 is any different. You
still cannot have two (major) versions of libruby without patching the
build system to set the soname properly.

Thanks

Michal

=end

[nobu (Nobuyoshi Nakada)]

=begin
Hi,

Please create new tickets for each issues.

At Thu, 27 Aug 2009 19:59:29 +0900,
Michal Suchanek wrote in [ruby-core:25165]:

It's not like the situation with 1.8 vs 1.9 is any different. You
still cannot have two (major) versions of libruby without patching the
build system to set the soname properly.

Not true, as I have mentioned in [ruby-core:25101] already.

--
Nobu Nakada

=end

[nobu (Nobuyoshi Nakada)]

• Category set to core
• Target version set to 1.9.2
• ruby -v changed from ruby 1.8.6 (2009-08-04 patchlevel 383) [i686-darwin9.8.0] to darwin9.8.0

=begin

=end

[naruse (Yui NARUSE)]

• Status changed from Open to Rejected

=begin

=end