Dear David, I agree, that NaviServer's "private" libraries are perfect examples of Debian's exception rule.
so, i think, we should use the change that you suggested.

-g


Am 06.03.15 um 13:57 schrieb David Osborne:
Thanks - that was very helpful Gustaf.

I'm using the Debian tclConfig.sh which does indeed clear those variables.

# Flags to pass to ld, such as "-R /usr/local/tcl/lib", that tell the
# run-time dynamic linker where to look for shared libraries such as
# libtcl.so.  Used when linking applications.  Only works if there
# is a variable "LIB_RUNTIME_DIR" defined in the Makefile.
TCL_CC_SEARCH_FLAGS=''
TCL_LD_SEARCH_FLAGS=''

Debian does discourage the use of rpath in general except in the following case which I think applies in this instance:
https://wiki.debian.org/RpathIssue
"Currently, the only generally accepted use of this feature in Debian is to add non-standard library path (like /usr/lib/<package>) to libraries that are only intended to be used by the executables or other libraries within the same source package."


So I can understand why Tcl8.5 doesn't have rpath's set in tclConfig.sh on Debian.

Which would be the best way to include an rpath to the private naviserver libraries (libnsdb.so, libnsd.so, libnsthread.so etc.) during the Naviserver build so the nsd binary can find them?

It seems strange that I would need to change the TCL_*_SEARCH_FLAGS to achieve this.



On 6 March 2015 at 10:12, Gustaf Neumann <neum...@wu.ac.at <mailto:neum...@wu.ac.at>> wrote:

    Hi David,

    When i add the following two lines

        echo "---TCL_CC_SEARCH_FLAGS=$TCL_CC_SEARCH_FLAGS
    CC_SEARCH_FLAGS=$CC_SEARCH_FLAGS"
        echo "---TCL_LD_SEARCH_FLAGS=$TCL_LD_SEARCH_FLAGS
    LD_SEARCH_FLAGS=$LD_SEARCH_FLAGS"

    before the setting of CCRFLAG and LDRFLAG on ubuntu (12.04.5 LTS),
    i see
    on the console

       ---TCL_CC_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR}
    CC_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR}
       ---TCL_LD_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR}
    LD_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR}

    i.e., CC_SEARCH_FLAGS is the same as TCL_CC_SEARCH_FLAGS, etc.
    i would assume that this is on your system different. It looks to
    me as if
    the TCL_* variants should be used, since these are tailored for Tcl.

    The TCL_* variables are set in the used tclConfig.sh. Which
    tclConfig.sh are you using?
    is it a "private" one or the Debian one?

    My suspicion is that some distros do not like the search-flags and
    clear it...

    -g

    Am 05.03.15 um 16:01 schrieb David Osborne:
    Hi again,

    I've been struggling to get --enable-rpath to work in our build
    (on Debian Wheezy). Up to now I'd always been patching
    Makefile.global.in <http://Makefile.global.in> during the Debian
    build to add -Wl,-rpath manually.

    Looking at --enable-rpath. It seems to trigger the substitution
    of -Wl,-rpath into CC_SEARCH_FLAGS and LD_SEARCH_FLAGS by
    m4/tcl.m4, but they weren't being pulled into the configure step.

    But I noticed configure.ac <http://configure.ac> references
    $TCL_CC_SEARCH_FLAGS & $TCL_LD_SEARCH_FLAGS when setting LDRFLAGS
    & CCRFLAGS, but I couldn't see where they were being set.

    Could the following diff be what is intended?
    Seems to make it work for me...

    $ hg diff
    diff -r 20530df80f68 configure.ac <http://configure.ac>
    --- a/configure.ac <http://configure.ac>      Tue Mar 03 09:07:48
    2015 +0000
    +++ b/configure.ac <http://configure.ac>      Thu Mar 05 14:55:42
    2015 +0000
    @@ -133,8 +133,8 @@
     LDSO="\$(LDLIB)"
     CCRPATHS="\$(CCRPATH)"
     LDRPATHS="\$(LDRPATH)"
    -  CCRFLAG=$TCL_CC_SEARCH_FLAGS
    -  LDRFLAG=$TCL_LD_SEARCH_FLAGS
    +  CCRFLAG=$CC_SEARCH_FLAGS
    +  LDRFLAG=$LD_SEARCH_FLAGS
         if test "$CCRFLAG" = "" ; then
     CCRPATH=
         fi




------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Reply via email to