Help concordance find libconcord and use libtool to link

[swt2c]

Fixes long-standing annoyance of having to override CFLAGS and LDFLAGS to tell concordance how to find libconcord and also removes platform specific code for linking, leaving this to libtool.

Signed-off-by: Scott Talbert swt@techie.net

[jaymzh]

The problem with this is that it ends up building from a related builddir and not waht's installed on the system. but it'll RUN from what's installed on the system and that's all sorts of badness and leads to runtime errors. People should install the libs before building the binary.

[swt2c]

It won't run from the system installed version: [talbert@easel git-concordance]$ ldd concordance/.libs/concordance | grep libconcord libconcord.so.4 => /home/talbert/concordance/git-concordance/libconcord/.libs/libconcord.so.4 (0x00007f023e19c000)

Also, building against an installed version doesn't generally isn't how most distribution build systems work. They generally do all the building first, and then do all the installing together.

[jaymzh]

Huh?

When I ./configure; make I get:

[phil@rider (master) concordance]$ ldd ./concordance | grep libconco
    libconcord.so.4 => /usr/lib/libconcord.so.4 (0x00007f5fd9bcd000)

libconcord is a builddep of concordance - rpms/debs/etc install or require builddeps to be installed before you can build the dependent source.

[swt2c]

Hmm. That is odd. Maybe it is because I don't have a /usr/lib/libconcord.so.4 installed?

Yes, but on Fedora and Debian, for example, libconcord and concordance are built from the same source package, so there are no build deps to be installed. In Fedora, libconcord used to be a separate source package but I merged them because it was pretty pointless for them to be separate.

[jaymzh]

How do you figure. There's three front-ends to libconcord - you own two of them. There's concordance, congruity and mhgui. Most people will never need concordance. The whole goal was to separate them out so they can be completely separate.

[swt2c]

Yes, the binary packages are separate - you can install the libconcord RPM, for example, without installing the concordance RPM, but they are all built from a single RPM specfile and source RPM. Same for debian, one source deb.

[jaymzh]

For the average user building from source, this should use what's on the system. The packager is the advanced user doing the non-standard thing (effectively "magic" to work around the standard path), and it makes sense for spec files and debian/rules files to specify include/lib paths of '../llibcocncord/..' - right? If you've installed libcocnord concordance does the right thing (see above outout) and will complain if those libraries aren't found in system paths (as it should). So for packagers, I'd imagine something like --with-libconcord=../libconcord would work. But it definitely shouldn't work this way for a standard user...

[swt2c]

I'm still not seeing a lot of cases where building against ../libconcord isn't the right thing to do.

Case 1: user downloads tarball, compiles libconcord, installs libconcord, compiles concordance -> OK, since installed libconcord matches ../libconcord.

Case 2: user downloads tarball, compiles libconcord, doesn't install libconcord, compiles concordance -> OK, concordance matches libconcord

Case 3: user downloads tarball, doesn't compile libconcord but has a libconcord already installed, compiles concordance -> Possible soname mismatch, but that is probably desired. Otherwise, the user would be running a newer concordance with an old libconcord, probably not recommended.

[jaymzh]

Case 1: User has libconcord from distro, installs concordance, it builds and installs fine, then gives weird symbol errors. Could have been caught easily at configure/make time that proper reqs weren't installed

Case 2: User has nothing installed, tries to install, doesn't install libconcord, concordance builds and installs, but then doesn't work.

The build defaults are optimized for the average user installing outside of their distro.

I never did finish the split and put them in separate repos which would have made this more clear... maybe I should.

I'm fine having a nice option that makes it easier for packagers, but I want the defaults to catch end-user errors earlier than later.

[swt2c]

If we're really concerned about making it easier for users, we should just have a single "./configure; make; make install" that compiles and installs both libconcord and concordance. Concordance is just a single C file after all. Putting a single C file into a separate repository doesn't make sense, IMHO. It's just unnecessary overhead and complication.

Take for example openssl. Most people probably don't use the openssl command line application, just the libraries. But the default build process builds the libraries and binary. They don't make you download a separate source package or run separate build commands just to make the command line application.

[jaymzh]

Fair point - I'd be OK with that, actually. If we want to restructure into a single directory and build process that dumps out the SO and the bin ala openssl. But while they're two build processes, the one should depend on the other.

Sorry for the delay, I wanted to think through that ;)

[swt2c]

Closing this as it doesn't seem important or necessary.