neon-config --la-file points to non-existent file

[David Allouche]

With libneon26-dev 0.26.2-3.1, "neon-config --la-file" outputs "/usr/lib/libneon.la" but this file does not exist.

That break manual build (not from source package) of some projects such as subversion.

[Max Bowsher (maxb)]

I think that being unable to use a library to satisfy the dependencies of manual from-source builds is a fairly serious bug. Could someone with the necessary privileges tag this bug with a suitably high "Importance" value, please?

[troycurtisjr (troycurtisjr)]

I can confirm that this is a real problem, Subversion will not build from source without this file!

[Hyrum Wright (hyrumwright)]

This is also a problem in Hardy, using the libneon27-dev package:

hwright@spock:~/dev/svn-1.5.x$ neon-config --la-file
/usr/lib/libneon.la
hwright@spock:~/dev/svn-1.5.x$ ls /usr/lib/libneon.la
ls: cannot access /usr/lib/libneon.la: No such file or directory

[dave_rodgman (dav1dr)]

I can confirm libneon27-dev is also affected.

[Christoph Roeder (brightdroid)]

A year later and it's still not fixed... not even in 0.28.2-2

see: https://bugs.launchpad.net/ubuntu/+source/neon27/0.28.2-2

[bjarkef (bjarkef-deactivatedaccount)]

Any update on this? When can I finish compiling subversion?

[Christoph Roeder (brightdroid)]

I used the "Subversion 1.5.0 Dependencies" [1] until this bug get fixed.

[1] http://subversion.tigris.org/downloads/subversion-deps-1.5.0.tar.bz2

[djmurf (djmurf)]

To complete the subversion build, you can edit Makfile and change:

NEON_LIBS = /usr/lib/libneon.la

to

NEON_LIBS = /usr/lib/libneon.so

This will create an external dependency on libneon.so, but this really isn't a problem.

Dean

[djmurf (djmurf)]

Sorry -- above post should read:

To complete the subversion build, you can edit "Makefile" ....

[Catone (catone)]

IMHO, it'll be more comfortable to fix neon-config, what is used by configure scripts ( of subversion, for example ).
Patch is in attachment. Just apply it to /usr/bin/neon-config.
Hope it helps.

[David Allouche (ddaa)]

Catone, thanks for submitting a patch, but I think it is a bad solution, for at least two reasons.

First, it's an Ubuntu-specific hack as a conditional. I think it unlikely to be merged upstream. If it's not going to be merged upstream, we do not need the conditional.

If we remove the conditional, the second problem becomes apparent. This patch makes neon-config lie. When provided the --la-file option, that would print the location of a .so file.

There are really only two sensible ways to go forward:

 1. Include the .la file in the Ubuntu package of libneon. Why is it even removed in the first place?

 2. Trick question. There's actually only sensible solution that will fix the "cannot build upstream tarballs".

[Catone (catone)]

Agreed. It's not a solution - it's a rather dirty hack.
I'm just not skilled enough to fix package.. or I think so. :)

[Catone (catone)]

After looking deeply into problem...

1. libneon.la was removed according to Debian policy
2. Debian policy will not be changed in near future
3. Subversion ( for example ) do not want to make their configure scripts OS-dependent

This confrontation lasts for years, and after I've read enough posts about it - I don't think that there will be done anything about it...

IMHO, the best solution will be to make neon-dependent configuration script ( i.e. subversion's autoconf ) OS dependent ( or at least pkg-config dependent ), but they don't want to...

Somebody should make first step here. It's not a good looking situation when debian-based OSes are not compatible with subversion development.

Printing location of .so file if .la file is absent is not quite right, but if we take that --la-file option is called to determine library against which link should be made, then .so answer is ok, imho. Probably with some warning, visible to user, to let them know what was done.

In other words, something like attachment.

It is not a good looking solution, nor a 'good style' solution, it's just a workaround, but I think it's better then 'Subversion sources are incompatible with Debian-based OSes without hand-work'..

[Max Bowsher (maxb)]

Do you know why Debian likes to remove .la files?

[Catone (catone)]

AFAIK, .la file claimed to be unnecessary for proper libtool functionality. And more importantly - software shouldn't know about what lib in particular it will be linked - it's libtool job to decide.

Quote:
"libtool functions fine without a
.la file, the need for this file was artificial created by neon-config
having an option to expose the .la filename, which AFAICT applications
never actually needed."

Main threads discussing this problem:
Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386652 - removing .la from neon
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400140 - la file missing bug
http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries - lib's policy

Subversion:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=647733 - attempt to fix missing libneon.la
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=659159 - missing libneon.la

[Max Bowsher (maxb)]

Looking in my /usr/lib/ on Intrepid I see quite a few .la files. If all those libraries can reasonably have one, why not Neon?

Furthermore, quoting from the Debian policy as linked in Catone's comment: "Packages that use libtool to create shared libraries should include the .la files in the -dev package".

Therefore, please put the .la file back.

[Thomas Hotz (thotz-deactivatedaccount)]

Is this still an issue for you? What Ubuntu version do you use? Thank you for telling us!

[David Allouche (ddaa)]

Good grief! I don't care nearly enough anymore to try and build svn from source. It's been 4 years! I've moved to other stuff.

Have a nice day.