0004984: Why neon requires application to be linked with openssl ?

(0010037)
dam (administrator)
2012-07-18 00:24

I didn't write the pkgconfig files myself, so I guess the neon guys hopefully do it right. The reason I know is that if libfoo has a global variable and app links to libfoo and libbar which also links to libfoo they use two separate copies of the global variable instead of a shared one. I ran into this for the perl backend for OpenLDAP where the perl modules were not linked directly to libperl.so resulting in strange behaviour.
Apart from that I have no idea how to check this. Ask upstream?

(0010038)
yann (developer)
2012-07-18 00:31

Hi Dam,

I suppose that if there was a global variable, I should have seen it during the runtime linking phase. But that could also be because cadaver doesn't use a feature that requires a direct linking with ssl.

Asking upstream is definitely a good solution. We can also check wthe situation in pother distros.

Yann

(0010040)
yann (developer)
2012-07-18 00:40

Just checked under debian, neon-config --libs just returns -lneon

Do you know how the output of this command is generated during the build phase ?

(0010042)
dam (administrator)
2012-07-18 00:46

It is, from neon-config.in with @NEON_LIBS@ which is generated from pkgconfig by picking up the flags from the dependent libs. Can you look up the build recipe from Debian?

(0010043)
yann (developer)
2012-07-18 00:54

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358042 [^]

(0010044)
yann (developer)
2012-07-18 00:58

The Debian patch:

  * Fix SNI TLS breakage until upstream fix (closes: #569639).yann@home:/tmp/neon27-0.29.6/debian/patches$ cat don*
Bug-Debian: http://bugs.debian.org/470519 [^]
Last-Update: <2011-07-05>

--- neon27-0.29.6.orig/neon-config.in
+++ neon27-0.29.6/neon-config.in
@@ -16,7 +16,6 @@ Known values for OPTION are:

   --prefix=DIR change neon prefix [default $prefix]
   --libs print library linking information
- --la-file print location of libtool .la file
   --cflags print pre-processor and compiler flags
   --help display this help and exit
   --version output version information
@@ -73,7 +72,7 @@ while test $# -gt 0; do
                ;;

     --libs)
- LIBS="-lneon @NEON_LIBS@"
+ LIBS="-lneon @NEON_LTLIBS@"
        # Don't add standard library paths
         if test "$prefix" != "/usr"; then
            LIBS="-L${libdir} ${LIBS}"
@@ -81,10 +80,6 @@ while test $# -gt 0; do
        echo @user_LDFLAGS@ ${LIBS}
        ;;

- --la-file)
- echo ${libdir}/libneon.la
- ;;
-
     --support)
        shift

(0010045)
yann (developer)
2012-07-18 00:59

Of course it would be better to still bring this upstream

(0010046)
yann (developer)
2012-07-18 01:04

It seems the neon.pc makes a distinction. What is the output of pkgconfig for neon ?

(0010047)
yann (developer)
2012-07-18 01:13

Hmm maybe neon-config output all these libraries for the static linking case.

Notes
(0010037) dam (administrator) 2012-07-18 00:24	I didn't write the pkgconfig files myself, so I guess the neon guys hopefully do it right. The reason I know is that if libfoo has a global variable and app links to libfoo and libbar which also links to libfoo they use two separate copies of the global variable instead of a shared one. I ran into this for the perl backend for OpenLDAP where the perl modules were not linked directly to libperl.so resulting in strange behaviour. Apart from that I have no idea how to check this. Ask upstream?

(0010038) yann (developer) 2012-07-18 00:31	Hi Dam, I suppose that if there was a global variable, I should have seen it during the runtime linking phase. But that could also be because cadaver doesn't use a feature that requires a direct linking with ssl. Asking upstream is definitely a good solution. We can also check wthe situation in pother distros. Yann

(0010040) yann (developer) 2012-07-18 00:40	Just checked under debian, neon-config --libs just returns -lneon Do you know how the output of this command is generated during the build phase ?

(0010042) dam (administrator) 2012-07-18 00:46	It is, from neon-config.in with @NEON_LIBS@ which is generated from pkgconfig by picking up the flags from the dependent libs. Can you look up the build recipe from Debian?

(0010043) yann (developer) 2012-07-18 00:54	See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358042 [^]

(0010044) yann (developer) 2012-07-18 00:58	The Debian patch: * Fix SNI TLS breakage until upstream fix (closes: #569639).yann@home:/tmp/neon27-0.29.6/debian/patches$ cat don* Bug-Debian: http://bugs.debian.org/470519 [^] Last-Update: <2011-07-05> --- neon27-0.29.6.orig/neon-config.in +++ neon27-0.29.6/neon-config.in @@ -16,7 +16,6 @@ Known values for OPTION are: --prefix=DIR change neon prefix [default $prefix] --libs print library linking information - --la-file print location of libtool .la file --cflags print pre-processor and compiler flags --help display this help and exit --version output version information @@ -73,7 +72,7 @@ while test $# -gt 0; do ;; --libs) - LIBS="-lneon @NEON_LIBS@" + LIBS="-lneon @NEON_LTLIBS@" # Don't add standard library paths if test "$prefix" != "/usr"; then LIBS="-L${libdir} ${LIBS}" @@ -81,10 +80,6 @@ while test $# -gt 0; do echo @user_LDFLAGS@ ${LIBS} ;; - --la-file) - echo ${libdir}/libneon.la - ;; - --support) shift

(0010045) yann (developer) 2012-07-18 00:59	Of course it would be better to still bring this upstream

(0010046) yann (developer) 2012-07-18 01:04	It seems the neon.pc makes a distinction. What is the output of pkgconfig for neon ?

(0010047) yann (developer) 2012-07-18 01:13	Hmm maybe neon-config output all these libraries for the static linking case.

Relationships

OpenCSW Bug Tracker