Project

General

Profile

Actions

Bug #1991

closed

ruby should use twolevel namespace on OS X

Added by hramrach (Michal Suchanek) over 14 years ago. Updated almost 13 years ago.

Status:
Rejected
Assignee:
-
Target version:
ruby -v:
darwin9.8.0
Backport:
[ruby-core:25086]

Description

=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


Files

ruby18-twolevel.patch (2.33 KB) ruby18-twolevel.patch change linker options for OS X hramrach (Michal Suchanek), 08/24/2009 08:14 PM
Actions #1

Updated by shyouhei (Shyouhei Urabe) over 14 years ago

=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

Actions #2

Updated by hramrach (Michal Suchanek) over 14 years ago

=begin
2009/8/24 Shyouhei Urabe :

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

Actions #3

Updated by hramrach (Michal Suchanek) over 14 years ago

=begin
2009/8/24 Michal Suchanek :

2009/8/24 Shyouhei Urabe :

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

Actions #4

Updated by shyouhei (Shyouhei Urabe) over 14 years ago

=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

Actions #5

Updated by hramrach (Michal Suchanek) over 14 years ago

=begin
2009/8/24 Shyouhei Urabe :

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

Actions #6

Updated by shyouhei (Shyouhei Urabe) over 14 years ago

=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

Actions #7

Updated by nobu (Nobuyoshi Nakada) over 14 years ago

=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

Actions #8

Updated by hramrach (Michal Suchanek) over 14 years ago

=begin
2009/8/24 Nobuyoshi Nakada :

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

Actions #9

Updated by shyouhei (Shyouhei Urabe) over 14 years ago

=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

Actions #10

Updated by hramrach (Michal Suchanek) over 14 years ago

=begin
2009/8/27 Urabe Shyouhei :

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

Actions #11

Updated by nobu (Nobuyoshi Nakada) over 14 years ago

=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

Actions #12

Updated by nobu (Nobuyoshi Nakada) over 14 years ago

  • 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

Actions #13

Updated by naruse (Yui NARUSE) over 14 years ago

  • Status changed from Open to Rejected

=begin

=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0