GNU bug report logs - #22430
Relocation error with libstdbuf.so on Solaris SPARC with Studio compilation.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22430 in the body.
You can then email your comments to 22430 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rich Burridge <rich.burridge <at> oracle.com>
To: bug-coreutils <at> gnu.org
Subject: Relocation error with libstdbuf.so on Solaris SPARC with Studio
 compilation.
Date: Fri, 22 Jan 2016 02:28:26 -0800

[Message part 1 (text/plain, inline)]

Hi,

We've noticed an interesting problem recently with the version of stdbuf
(really libstdbuf.so) from coreutils version 8.24 on SPARC in Solaris 12.

If you do something like:

  $ stdbuf -oL echo

it generates:

ld.so.1: echo: fatal: relocation error: file /usr/lib/64/libstdbuf.so: 
symbol
program_name: referenced symbol not found
Killed

but that same command works just fine for stdbuf and libstdbuf.so from
8.24 in Solaris 12 on x86.

There's a similar problem for the 32-bit version as well. I'll use that
to describe what's going on.

I took the command we use to compile 32-bit libstdbuf.c on SPARC:

 $ /ws/on12-tools/SUNWspro/solarisstudio12.4/bin/cc  -I. 
-I/builds/richb/22510525-coreutils/components/coreutils/coreutils-8.24 
-I./lib  -Ilib 
-I/builds/richb/22510525-coreutils/components/coreutils/coreutils-8.24/lib 
-Isrc 
-I/builds/richb/22510525-coreutils/components/coreutils/coreutils-8.24/src 
-I/usr/include/gmp -D_REENTRANT -fPIC   -m32 -xO4 -xtarget=ultra2 
-xarch=sparcvis -xchip=ultra2 -Qoption cg -xregs=no%appl -W2,-xwrap_int  
-xmemalign=8s -mt  -c -o src/src_libstdbuf_so-libstdbuf.o `test -f 
'src/libstdbuf.c' || echo 
'/builds/richb/22510525-coreutils/components/coreutils/coreutils-8.24/'`src/libstdbuf.c

and adjusted that to use "-E" instead of "-c" and reran it to generate a
self-contained lsb.c source file (attached).

I then compiled/linked that on SPARC and x86 (using the commands that are
generated by our Userland build environment) and noticed the following 
differences:

x86:

  $ /ws/on12-tools/SUNWspro/solarisstudio12.4/bin/cc -fPIC -m32 -xO4 
'-xchip=pentium' '-xregs=no%frameptr' -mt -shared -o lsb.so lsb.c
"src/libstdbuf.c", line 97: warning: shift count negative or too big: << 63

  $ elfdump lsb.so | grep program_name
  $

SPARC:

  $ /ws/on12-tools/SUNWspro/solarisstudio12.4/bin/cc -fPIC -m32 -xO4 
'-xtarget=ultra2' '-xarch=sparcvis' '-xchip=ultra2' -Qoption cg 
'-xregs=no%appl' -W2,-xwrap_int '-xmemalign=8s' -mt -shared -o lsb.so lsb.c
"src/libstdbuf.c", line 97: warning: shift count negative or too big: << 63

  $ elfdump lsb.so | grep program_name
    [1]        0   0x4  OBJT GLOB  D    0 UNDEF program_name
   [42]        0   0x4  OBJT GLOB  D    0 UNDEF program_name
       2  [1]     program_name
    [1]  0x1177c     0  R_SPARC_GLOB_DAT    program_name
   [12]  R_SPARC_GLOB_DAT  0x1177c     0      0  .got program_name
  $


Now you can see from lsb.c that the code includes:

extern const char *program_name;

...

static inline void
emit_try_help (void)
{
  fprintf ( ( & __iob [ 2 ] ),  gettext ( "Try '%s --help' for more 
information.\n" ), program_name);
}

It looks like the Studio compiler for x86 is nicely optimizing the
emit_try_help() away as it's not being used, but the SPARC version of
the Studio compiler isn't, and is causing the problem.

(Note that this isn't a problem with GNU compiling/linking on Solaris 
for both
x86 and SPARC).

Now I can "fix" this by adding progname.o (where the program_name variable
is defined) to libstdbuf.so as it's being linked.


  $ /ws/on12-tools/SUNWspro/solarisstudio12.4/bin/cc -fPIC -m32 -xO4 
'-xarch=sparcvis' '-xchip=ultra2' '-xregs=no%appl' '-xtarget=ultra2' 
-Qoption cg -W2,-xwrap_int '-xmemalign=8s' -mt -shared -o mylsb.so 
build/sparcv7/lib/progname.o lsb.c
"src/libstdbuf.c", line 97: warning: shift count negative or too big: << 63

  $ elfdump mylsb.so | grep program_name
   [20]  0x11ae4   0x4  OBJT GLOB  D    0 .data program_name
   [26]   0x1010  0xf0  FUNC GLOB  D    0 .text set_program_name
   [63]  0x11ae4   0x4  OBJT GLOB  D    0 .data program_name
   [69]   0x1010  0xf0  FUNC GLOB  D    0 .text set_program_name
   [42]   0x1010  0xf0  FUNC GLOB  D    0 .text set_program_name
   [36]  0x11ae4   0x4  OBJT GLOB  D    0 .data program_name
          [20]    program_name
      26  [26]    set_program_name
    [2]  0x11a10     0  R_SPARC_GLOB_DAT    program_name
   [23]  R_SPARC_HI22       0x10d4     0      0  .text program_name
   [24]  R_SPARC_LO10       0x10d8     0      0  .text program_name
   [25]  R_SPARC_GLOB_DAT  0x11a10     0      0  .got program_name

but program_name really is an undefined variable here in this context, 
so I was
wondering if there was a better fix that was needed here.

Thanks in consideration.

PS: Going to bed now; back online in a few hours...

[lsb.c (text/x-csrc, attachment)]

Message #8 received at 22430 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Rich Burridge <rich.burridge <at> oracle.com>, 22430 <at> debbugs.gnu.org
Subject: Re: bug#22430: Relocation error with libstdbuf.so on Solaris SPARC
 with Studio compilation.
Date: Sun, 24 Jan 2016 09:06:30 -0800

On 22/01/16 02:28, Rich Burridge wrote:
> Hi,
> 
> We've noticed an interesting problem recently with the version of stdbuf
> (really libstdbuf.so) from coreutils version 8.24 on SPARC in Solaris 12.
> 
> If you do something like:
> 
>    $ stdbuf -oL echo
> 
> it generates:
> 
> ld.so.1: echo: fatal: relocation error: file /usr/lib/64/libstdbuf.so: 
> symbol
> program_name: referenced symbol not found
> Killed
> 
> but that same command works just fine for stdbuf and libstdbuf.so from
> 8.24 in Solaris 12 on x86.
> 
> There's a similar problem for the 32-bit version as well. I'll use that
> to describe what's going on.
> 
> I took the command we use to compile 32-bit libstdbuf.c on SPARC:
> 
>   $ /ws/on12-tools/SUNWspro/solarisstudio12.4/bin/cc  -I. 
> -I/builds/richb/22510525-coreutils/components/coreutils/coreutils-8.24 
> -I./lib  -Ilib 
> -I/builds/richb/22510525-coreutils/components/coreutils/coreutils-8.24/lib 
> -Isrc 
> -I/builds/richb/22510525-coreutils/components/coreutils/coreutils-8.24/src 
> -I/usr/include/gmp -D_REENTRANT -fPIC   -m32 -xO4 -xtarget=ultra2 
> -xarch=sparcvis -xchip=ultra2 -Qoption cg -xregs=no%appl -W2,-xwrap_int  
> -xmemalign=8s -mt  -c -o src/src_libstdbuf_so-libstdbuf.o `test -f 
> 'src/libstdbuf.c' || echo 
> '/builds/richb/22510525-coreutils/components/coreutils/coreutils-8.24/'`src/libstdbuf.c
> 
> and adjusted that to use "-E" instead of "-c" and reran it to generate a
> self-contained lsb.c source file (attached).
> 
> I then compiled/linked that on SPARC and x86 (using the commands that are
> generated by our Userland build environment) and noticed the following 
> differences:
> 
> x86:
> 
>    $ /ws/on12-tools/SUNWspro/solarisstudio12.4/bin/cc -fPIC -m32 -xO4 
> '-xchip=pentium' '-xregs=no%frameptr' -mt -shared -o lsb.so lsb.c
> "src/libstdbuf.c", line 97: warning: shift count negative or too big: << 63
> 
>    $ elfdump lsb.so | grep program_name
>    $
> 
> SPARC:
> 
>    $ /ws/on12-tools/SUNWspro/solarisstudio12.4/bin/cc -fPIC -m32 -xO4 
> '-xtarget=ultra2' '-xarch=sparcvis' '-xchip=ultra2' -Qoption cg 
> '-xregs=no%appl' -W2,-xwrap_int '-xmemalign=8s' -mt -shared -o lsb.so lsb.c
> "src/libstdbuf.c", line 97: warning: shift count negative or too big: << 63
> 
>    $ elfdump lsb.so | grep program_name
>      [1]        0   0x4  OBJT GLOB  D    0 UNDEF program_name
>     [42]        0   0x4  OBJT GLOB  D    0 UNDEF program_name
>         2  [1]     program_name
>      [1]  0x1177c     0  R_SPARC_GLOB_DAT    program_name
>     [12]  R_SPARC_GLOB_DAT  0x1177c     0      0  .got program_name
>    $
> 
> 
> Now you can see from lsb.c that the code includes:
> 
> extern const char *program_name;
> 
> ...
> 
> static inline void
> emit_try_help (void)
> {
>    fprintf ( ( & __iob [ 2 ] ),  gettext ( "Try '%s --help' for more 
> information.\n" ), program_name);
> }
> 
> It looks like the Studio compiler for x86 is nicely optimizing the
> emit_try_help() away as it's not being used, but the SPARC version of
> the Studio compiler isn't, and is causing the problem.
> 
> (Note that this isn't a problem with GNU compiling/linking on Solaris 
> for both
> x86 and SPARC).
> 
> Now I can "fix" this by adding progname.o (where the program_name variable
> is defined) to libstdbuf.so as it's being linked.
> 
> 
>    $ /ws/on12-tools/SUNWspro/solarisstudio12.4/bin/cc -fPIC -m32 -xO4 
> '-xarch=sparcvis' '-xchip=ultra2' '-xregs=no%appl' '-xtarget=ultra2' 
> -Qoption cg -W2,-xwrap_int '-xmemalign=8s' -mt -shared -o mylsb.so 
> build/sparcv7/lib/progname.o lsb.c
> "src/libstdbuf.c", line 97: warning: shift count negative or too big: << 63
> 
>    $ elfdump mylsb.so | grep program_name
>     [20]  0x11ae4   0x4  OBJT GLOB  D    0 .data program_name
>     [26]   0x1010  0xf0  FUNC GLOB  D    0 .text set_program_name
>     [63]  0x11ae4   0x4  OBJT GLOB  D    0 .data program_name
>     [69]   0x1010  0xf0  FUNC GLOB  D    0 .text set_program_name
>     [42]   0x1010  0xf0  FUNC GLOB  D    0 .text set_program_name
>     [36]  0x11ae4   0x4  OBJT GLOB  D    0 .data program_name
>            [20]    program_name
>        26  [26]    set_program_name
>      [2]  0x11a10     0  R_SPARC_GLOB_DAT    program_name
>     [23]  R_SPARC_HI22       0x10d4     0      0  .text program_name
>     [24]  R_SPARC_LO10       0x10d8     0      0  .text program_name
>     [25]  R_SPARC_GLOB_DAT  0x11a10     0      0  .got program_name
> 
> but program_name really is an undefined variable here in this context, 
> so I was
> wondering if there was a better fix that was needed here.
> 
> Thanks in consideration.
> 
> PS: Going to bed now; back online in a few hours...

The simplest fix would be to turn it into a macro:

diff --git a/src/system.h b/src/system.h
index 9898bc7..857e56d 100644
--- a/src/system.h
+++ b/src/system.h
@@ -650,11 +650,16 @@ emit_ancillary_info (char const *program)
           node, node == program ? " invocation" : "");
 }

-static inline void
-emit_try_help (void)
-{
-  fprintf (stderr, _("Try '%s --help' for more information.\n"), program_name);
-}
+/* A macro rather than an inline function, as it references
+   the global program_name, which causes run time linking issues
+   in libstdbuf.so where unused functions are not removed by the linker.  */
+#define emit_try_help() \
+  do \
+    { \
+      fprintf (stderr, _("Try '%s --help' for more information.\n"), \
+               program_name); \
+    } \
+  while (0)

 #include "inttostr.h"

Message #11 received at 22430 <at> debbugs.gnu.org (full text, mbox):

From: Rich Burridge <rich.burridge <at> oracle.com>
To: Pádraig Brady <P <at> draigBrady.com>, 22430 <at> debbugs.gnu.org
Subject: Re: bug#22430: Relocation error with libstdbuf.so on Solaris SPARC
 with Studio compilation.
Date: Sun, 24 Jan 2016 13:51:43 -0800

On 01/24/2016 09:06 AM, Pádraig Brady wrote:
> ...
> The simplest fix would be to turn it into a macro:
>
> diff --git a/src/system.h b/src/system.h
> index 9898bc7..857e56d 100644
> --- a/src/system.h
> +++ b/src/system.h
> @@ -650,11 +650,16 @@ emit_ancillary_info (char const *program)
>             node, node == program ? " invocation" : "");
>   }
>
> -static inline void
> -emit_try_help (void)
> -{
> -  fprintf (stderr, _("Try '%s --help' for more information.\n"), program_name);
> -}
> +/* A macro rather than an inline function, as it references
> +   the global program_name, which causes run time linking issues
> +   in libstdbuf.so where unused functions are not removed by the linker.  */
> +#define emit_try_help() \
> +  do \
> +    { \
> +      fprintf (stderr, _("Try '%s --help' for more information.\n"), \
> +               program_name); \
> +    } \
> +  while (0)
>
>   #include "inttostr.h"

This works great.

Thanks!

Message #16 received at 22430 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Rich Burridge <rich.burridge <at> oracle.com>, 22430 <at> debbugs.gnu.org
Subject: Re: bug#22430: Relocation error with libstdbuf.so on Solaris SPARC
 with Studio compilation.
Date: Mon, 25 Jan 2016 08:23:03 +0100

On 01/24/2016 06:06 PM, Pádraig Brady wrote:
> The simplest fix would be to turn it into a macro:

Thinking about it again, we could've passed program_name as
parameter to emit_try_help(), too, right?  (... which would've
meant a change to usage() of all programs, of course.)

Have a nice day,
Berny

Message #19 received at 22430 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Rich Burridge <rich.burridge <at> oracle.com>, 22430 <at> debbugs.gnu.org
Subject: Re: bug#22430: Relocation error with libstdbuf.so on Solaris SPARC
 with Studio compilation.
Date: Mon, 25 Jan 2016 00:25:04 -0800

On 24/01/16 23:23, Bernhard Voelker wrote:
> On 01/24/2016 06:06 PM, Pádraig Brady wrote:
>> The simplest fix would be to turn it into a macro:
> 
> Thinking about it again, we could've passed program_name as
> parameter to emit_try_help(), too, right? 

yes.

> (... which would've
> meant a change to usage() of all programs, of course.)

right a more awkward patch

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.