bug#22455: sort-V not sorting correctly when minor version decimal places differ

[Assaf Gordon]

tag 22455 notabug
close 22455
thanks

Hello,

> On Jan 24, 2016, at 07:54, Vashti  wrote:
> [...]
> I understand that sort -V is not reliable in all cases, but this seems like
> quite a straightforward one.

"sort -V" is reliable (or at least - consistent and well defined in all cases).
It is likely that what you expect a "version string" to be is not how sort 
treats version strings. 

> $ echo -e '8.49\n8.5' | sort -V
> 8.5
> 8.49
> 
> I can produce the expected behaviour by correcting the second version
> number to two decimal places:
> 
> $ echo -e '8.49\n8.50' | sort -V
> 8.49
> 8.50
> 

First,
In gnu software versions (and in many other places), the number after the 
decimal point is not the same as a numeric decimal value.
Thus,
version "8.5" is "eight point five",
version "8.50" is "eight point fifty",
version "8.500" is "eight point five-hundred".
These are different versions, and "8.500" is the highest version number among 
them.

If you need numerical sorting, where "8.5" is equal to "8.50", then "-V" is not 
the correct sorting option (use "-n" for numeric sort).

Second,
It is incorrect to think of version numbers as decimal-point numbers (in the 
context of "sort -V").
"sort -V" follows the Debian policy regarding versions ( 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version ) .
Roughly speaking, there are no decimal-point numbers (e.g. "8.5").
Instead, a version string is divided into numeric parts (all digits) and 
non-numeric parts, and each part is compared separately.

The compared parts are then:
1. "8" vs "8"
2. "." vs "."
3. "5" vs "49"

The first two parts are equal, and in the last part, value "5" comes before 
"49".
The numeric sort does not care that the non-digit character is a decimal point 
- it has no special meaning.
Just as well, it might have been a word:

   $ printf "8.49\n8.5\n" | sort -V
   8.5
   8.49

   $ printf "8foo49\n8foo5\n" | sort -V
   8foo5
   8foo49

As such, I'm making this bug as closed, but discussion can continue by replying 
to this thread.

regards,
 - assaf
 

bug#22455: sort-V not sorting correctly when minor version decimal places differ

[Vashti]

Hi, I'm having an issue with a script using coreutils 8.25. Asked to sort
two version numbers, 8.49 and 8.5, it returns them in the wrong order, with
the lowest value second:

$ echo -e '8.49\n8.5' | sort -V
8.5
8.49

I can produce the expected behaviour by correcting the second version
number to two decimal places:

$ echo -e '8.49\n8.50' | sort -V
8.49
8.50

I understand that sort -V is not reliable in all cases, but this seems like
quite a straightforward one.

Thank you.

bug#22455: sort-V not sorting correctly when minor version decimal places differ

[Andreas Schwab]

Vashti  writes:

> Hi, I'm having an issue with a script using coreutils 8.25. Asked to sort
> two version numbers, 8.49 and 8.5, it returns them in the wrong order, with
> the lowest value second:
>
> $ echo -e '8.49\n8.5' | sort -V
> 8.5
> 8.49

5 < 49, so that looks correct.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#22430: Relocation error with libstdbuf.so on Solaris SPARC with Studio compilation.

[Bernhard Voelker]

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

bug#22430: Relocation error with libstdbuf.so on Solaris SPARC with Studio compilation.

[Pádraig Brady]

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  D0 UNDEF program_name
> [42]0   0x4  OBJT GLOB  D0 UNDEF program_name
> 2  [1] program_name
>  [1]  0x1177c 0  R_SPARC_GLOB_DATprogram_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  D0 .data program_name
> [26]   0x1010  0xf0  FUNC GLOB  D0 .text set_program_name
> [63]  0x11ae4   0x4  OBJT GLOB  D0 .data program_name
> [69]   0x1010  0xf0  FUNC GLOB  D0 .text set_program_name
> [42]   0x1010  0xf0  FUNC GLOB  D0 .text set_program_name
> [36]  0x11ae4   0x4  OBJT GLOB  D0 .data program_name
>[20]program_name
>26  [26]set_program_name
>  [2]  0x11a10 0  R_SPARC_GLOB_DATprogram_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 

bug#22430: Relocation error with libstdbuf.so on Solaris SPARC with Studio compilation.

[Rich Burridge]

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!