[Bug math/18915] libm.so is now a script and breaks backwards compat

[Bug math/18915] libm.so is now a script and breaks backwards compat

[simonas+bugzilla.sourceware.org at kazlauskas dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

Simonas <simonas+bugzilla.sourceware.org at kazlauskas dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|libm.so is not a script and |libm.so is now a script and
                   |breaks backwards compat     |breaks backwards compat

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18915] New: libm.so is not a script and breaks backwards compat

[simonas+bugzilla.sourceware.org at kazlauskas dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

            Bug ID: 18915
           Summary: libm.so is not a script and breaks backwards compat
           Product: glibc
           Version: 2.22
            Status: NEW
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: simonas+bugzilla.sourceware.org at kazlauskas dot me
  Target Milestone: ---

libm.so previously used to be an ELF shared library, but now it is not. dlopen
and various ELF tools do not support ld scripts and therefore this change
breaks backwards compatibility.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18915] libm.so is now a script and breaks backwards compat

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
You should be using LIBM_SO from <gnu/lib-names.h>.  The use of *.so in dlopen
was never supported since those files are not part of the runtime environment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18915] libm.so is now a script and breaks backwards compat

[simonas+bugzilla.sourceware.org at kazlauskas dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

--- Comment #2 from Simonas <simonas+bugzilla.sourceware.org at kazlauskas dot me> ---
What is alternative to *.so in dlopen then? dlopen("libm") is pretty much
equivalent to dlopen("libm.so") in a sense that it tries opening the same file.

> You should be using LIBM_SO from <gnu/lib-names.h>.

That is not an option outside the C/C++ compilers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18915] libm.so is now a script and breaks backwards compat

[simonas+bugzilla.sourceware.org at kazlauskas dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

--- Comment #3 from Simonas <simonas+bugzilla.sourceware.org at kazlauskas dot me> ---
> dlopen("libm") is pretty much equivalent to dlopen("libm.so") in a sense that it tries opening the same file.

Ignore that part.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18915] libm.so is now a script and breaks backwards compat

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
As discussed, this is not a bug.  GNU/Linux distributions do not in general
install libm.so by default (only if development packages are installed, because
it's only for use of the static linker not the dynamic linker), so binaries
referring to libm.so would never have worked reliably.  If you're using a
language without direct access to LIBM_SO, you need find some way for your
build process to extract the value of LIBM_SO (e.g. using your language's C
bindings support, or compiling a C file using LIBM_SO at configure time and
then extracting the string from the results of that compilation).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18915] libm.so is now a script and breaks backwards compat

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |fweimer at redhat dot com
         Resolution|INVALID                     |---
              Flags|                            |security-

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Simonas from comment #2)
> > You should be using LIBM_SO from <gnu/lib-names.h>.
> 
> That is not an option outside the C/C++ compilers.

What are you trying to do, exactly?  Maybe we can offer you a supported
interface for that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18915] libm.so is now a script and breaks backwards compat

[simonas+bugzilla.sourceware.org at kazlauskas dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

Simonas <simonas+bugzilla.sourceware.org at kazlauskas dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Simonas <simonas+bugzilla.sourceware.org at kazlauskas dot me> ---
> What are you trying to do, exactly?  Maybe we can offer you a supported interface for that.

I’d mostly like to be just able to do something along the lines of
`dlopen("X")` to load the appropriate libX shared library that exists in the
system for arbitrary X. When `libm.so` was a (link to a) proper shared library
you could simply do `dlopen("lib" "X" ".so")` (or some sort of runtime string
stitching), but now that is not possible anymore for "X" = "m". 

Writing this I realised there also are a few other libraries that do the ld
script thing, so it might be simply me approaching library search the wrong
way, which sounds about right.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-29647-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Sep 04 10:29:49 2015
Return-Path: <glibc-bugs-return-29647-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 44570 invoked by alias); 4 Sep 2015 10:29:49 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 44294 invoked by uid 48); 4 Sep 2015 10:29:43 -0000
From: "renemanasse at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug localedata/12676] Please add the new language_REGION locale ln_CD
Date: Fri, 04 Sep 2015 10:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: localedata
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: renemanasse at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: libc-locales at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-12676-131-cqZttvcD5L@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-12676-131@http.sourceware.org/bugzilla/>
References: <bug-12676-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-09/txt/msg00046.txt.bz2
Content-length: 695

https://sourceware.org/bugzilla/show_bug.cgi?id\x12676

RENE MANASSE <renemanasse at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |renemanasse at gmail dot com

--- Comment #6 from RENE MANASSE <renemanasse at gmail dot com> ---
Thx all about your suggestion,
i want to colloborate about my local language submitted.

I have again three languages to submit soom (Kikongo, swahili and Thsiluba for
DR Congo), and our team are ready to begin the translation.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18915] libm.so is now a script and breaks backwards compat

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

--- Comment #7 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Simonas from comment #6)
> > What are you trying to do, exactly?  Maybe we can offer you a supported interface for that.
> 
> I’d mostly like to be just able to do something along the lines of
> `dlopen("X")` to load the appropriate libX shared library that exists in the
> system for arbitrary X. When `libm.so` was a (link to a) proper shared
> library you could simply do `dlopen("lib" "X" ".so")` (or some sort of
> runtime string stitching), but now that is not possible anymore for "X" =
> "m". 

You need to specify the full soname.  If you use libm.so, you might well get
something that has a completely different ABI and does not match your
expectations at all.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-29652-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Sep 04 14:47:26 2015
Return-Path: <glibc-bugs-return-29652-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 10402 invoked by alias); 4 Sep 2015 14:47:26 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 10344 invoked by uid 55); 4 Sep 2015 14:47:21 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/14912] Rename non-installed bits/*.h headers
Date: Fri, 04 Sep 2015 14:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.16
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-14912-131-DirP1n2Rwu@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-14912-131@http.sourceware.org/bugzilla/>
References: <bug-14912-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-09/txt/msg00051.txt.bz2
Content-length: 2395

https://sourceware.org/bugzilla/show_bug.cgi?id\x14912

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  0f4341fbec937b26b34e0ee80ab903825c0c76d0 (commit)
      from  f834e6dc705c80550acf610d507b3e4cdf19693e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h\x0f4341fbec937b26b34e0ee80ab903825c0c76d0

commit 0f4341fbec937b26b34e0ee80ab903825c0c76d0
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Fri Sep 4 14:46:21 2015 +0000

    Rename bits/m68k-vdso.h to m68k-vdso.h (bug 14912).

    It was noted in
    <https://sourceware.org/ml/libc-alpha/2012-09/msg00305.html> that the
    bits/*.h naming scheme should only be used for installed headers.
    This patch renames bits/m68k-vdso.h to plain m68k-vdso.h to follow
    that convention.

        [BZ #14912]
        * sysdeps/unix/sysv/linux/m68k/bits/m68k-vdso.h: Move to ...
        * sysdeps/unix/sysv/linux/m68k/m68k-vdso.h: ...here.
        * sysdeps/unix/sysv/linux/m68k/coldfire/bits/atomic.h: Include
        <m68k-vdso.h> instead of <bits/m68k-vdso.h>.
        * sysdeps/unix/sysv/linux/m68k/init-first.c: Likewise.
        * sysdeps/unix/sysv/linux/m68k/m68k-helpers.S: Likewise.
        * sysdeps/unix/sysv/linux/m68k/m68k-vdso.c: Likewise.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                          |   11 +++++++++++
 .../unix/sysv/linux/m68k/coldfire/bits/atomic.h    |    2 +-
 sysdeps/unix/sysv/linux/m68k/init-first.c          |    2 +-
 sysdeps/unix/sysv/linux/m68k/m68k-helpers.S        |    2 +-
 sysdeps/unix/sysv/linux/m68k/m68k-vdso.c           |    2 +-
 .../unix/sysv/linux/m68k/{bits => }/m68k-vdso.h    |    0
 6 files changed, 15 insertions(+), 4 deletions(-)
 rename sysdeps/unix/sysv/linux/m68k/{bits => }/m68k-vdso.h (100%)

--
You are receiving this mail because:
You are on the CC list for the bug.