During the build process make calls sort with the now unsupported syntax +0 -1 (specifying field keys), the correct syntax would be -k1,2. A simple search and replace on graphviz-1.10/dotneato/common/Makefile seems sufficient. Reproducible: Always Steps to Reproduce: 1. emerge graphviz 2. 3. Actual Results: sed s/_//g color_names | sort +0 -1 > color_lib sort: invalid option -- 1
Created attachment 18434 [details, diff] Patch to replace antiquated sort syntax A simple sed statement replaces unsupported syntax for specifying sort fields in dotneato/common/Makefile. I'm no bash/sed expert, but it looks like it works (builds).
brandy, can you confirm the fix please?
The patch worked here. Thanks.
Both coreutils-5.0 and coreutils-5.0.91 still support the deprecated field-key syntax if we are using glibc-2.3.2 From sort.c in coreutils-5.0.91: if (obsolete_usage && optarg[0] == '+') { /* Treat +POS1 [-POS2] as a key if possible; but silently treat an operand as a file if it is not a valid +POS1. */ ..... if (optind != argc && argv[optind][0] == '-' && ISDIGIT (argv[optind][1])) ..... So the deprecated syntax is supported if obsolete_usage is true. This variable is set in sort.c: bool obsolete_usage = (posix2_version () < 200112); and the posix2_version function reads the _POSIX2_VERSION macro from /usr/include/unistd.h which is: #define _POSIX2_VERSION 199209L The only way I can reproduce this error is by setting the _POSIX2_VERSION macro to something greater than 200112 when installing coreutils.
Since glibc-cvs isn't currently supported, closing...
although it isnt supported, whats in glibc-cvs will soon be in glibc. Will this patch break existing glibc installs? if not, we might as well apply it now so to be proactive and prevent future bugs :)
I'm using glibc-2.3.2-r4, which defines _POSIX2_VERSION as 200112L.
We need to decide - either we fix this, or we 'fix' coreutils I guess. Johnm did a eclass to support this, althought its not sufficient in that it do not catch them all. I did though add it to the bug, but I see he have not updated it yet.
This is a duplicate of bug 28414 (or vice-versa), which has a "better" patch - the patch here misses one of the deprecated sort calls.
so which patch is better, here or in #28414 ?
*** This bug has been marked as a duplicate of 28414 ***