cwrappers ld transform problem

[Matthias Ferdinand <mf+ml.pkgsrc-users%netzwerkagentursaarland.de@localhost>]

Hi,

another problem with cwrappers under non-default circumstances. This one
shows in graphics/glew, which explicitly uses ld explicitly for linking,
not using gcc to pass through to ld:

    pkgsrc root@pkgsrc-debtesting:/opt/pkgsrc/work/pkgsrc/graphics/glew/default/glew-1.13.0 > grep -n -B 2 -w LD Makefile
    118-
    119-lib/$(LIB.SHARED): $(LIB.SOBJS)
    120:    $(LD) $(LDFLAGS) $(LDFLAGS.SO) -o $@ $^ $(LIB.LDFLAGS) $(LIB.LIBS)
    --
    166-
    167-lib/$(LIB.SHARED.MX): $(LIB.SOBJS.MX)
    168:    $(LD) $(LDFLAGS) $(LDFLAGS.SO.MX) -o $@ $^ $(LIB.LDFLAGS) $(LIB.LIBS)


My non-default setting in mk/compiler/gcc.mk:

    _LINKER_RPATH_FLAG=    --enable-new-dtags -R
    _COMPILER_RPATH_FLAG=  -Wl,${_LINKER_RPATH_FLAG:Q:C/([\\] )([\\] )*/,/g}

instead of

    _LINKER_RPATH_FLAG=    -R
    _COMPILER_RPATH_FLAG=  -Wl,${_LINKER_RPATH_FLAG}


This modification allows building e.g. minor python2.7 updates from
pkgsrc where libpython2.7 from pkgsrc is already installed. Without this
modification, "-R" forces the build process to link against previously
installed, no longer matching /opt/pkgsrc/lib/libpython2.7.so, in spite
of LD_LIBRARY_PATH pointing to the current build directory. That is a
quirk in Linux ldd/glibc, see
https://mail-index.netbsd.org/pkgsrc-users/2014/02/16/msg019321.html

Shell wrappers correctly transform
    -Wl,--enable-new-dtags,-R/opt/pkgsrc/lib
into
    --enable-new-dtags -R/opt/pkgsrc/lib
for ld invocation.

cwrapper does no such transform for ld, leading to this error message:

    ===> Building for glew-1.13.0
    cc -DGLEW_NO_GLU -DGLEW_BUILD -O2  -Wall -W -Iinclude -fPIC -Wcast-qual -ansi -pedantic  -o tmp/linux/default/shared/glew.o -c src/glew.c
    In file included from /opt/pkgsrc/work/pkgsrc/graphics/glew/default/.buildlink/include/X11/Xlib.h:47:0,
                     from include/GL/glxew.h:98,
                     from src/glew.c:38:
    /opt/pkgsrc/work/pkgsrc/graphics/glew/default/.buildlink/include/X11/Xfuncproto.h:160:24: warning: ISO C does not permit named variadic macros [-Wvariadic-macros]
     #define _X_NONNULL(args...)  __attribute__((nonnull(args)))
                            ^
    In file included from include/GL/glxew.h:100:0,
                     from src/glew.c:38:
    /opt/pkgsrc/work/pkgsrc/graphics/glew/default/.buildlink/include/X11/Xmd.h:110:23: warning: ISO C90 does not support 'long long' [-Wlong-long]
     typedef unsigned long long CARD64;
                           ^
=>  ld -L/opt/pkgsrc/lib -Wl,--enable-new-dtags,-R/opt/pkgsrc/lib -L/usr/lib -Wl,--enable-new-dtags,-R/usr/lib -shared -Wl,-soname=libGLEW.so.1.13 -o lib/libGLEW.so.1.13.0 tmp/linux/default/shared/glew.o -L/opt/pkgsrc/lib -L/usr/lib -lGL -lX11 -lpthread 
=>  ld: unrecognized option '--enable-new-dtags,-R/opt/pkgsrc/lib'
=>  ld: use the --help option for usage information
    Makefile:120: recipe for target 'lib/libGLEW.so.1.13.0' failed
    make: *** [lib/libGLEW.so.1.13.0] Error 1
    *** Error code 2



Since the variable name _COMPILER_RPATH_FLAG indicates it is to be used
for compiler (i.e. gcc) invocation, it might as well be a mistake in
glew configure or Makefile to use it as linker flags.

Not sure if it is really cwrappers fault. Shell wrappers might just be
generously covering over a wrong use of -Wl as an ld arg.


Regards
Matthias