Re: [HTCondor-devel] library flag generation in the cmake files

[Erik Paulson <epaulson@xxxxxxxxxxxx>]

I apologize if I'm boring most of you, but just for completeness, after digging into the Cmake source, I decided to try the most recent version of cmake, rather than /unsup/cmake/bin/cmake @ UW Comp Sci (which is cmake 2.8.7).

My locally-built version of cmake 2.8.10.2 correctly finds my system krb and ssl libraries, and builds Condor successfully.

-Erik

On Mon, Mar 25, 2013 at 1:49 PM, Erik Paulson <epaulson@xxxxxxxxxxxx> wrote:

Progress, but stuck again. 

First, I figured out my pcre problem. The big discovery - classad and classads are different targets, classad is dynamic and classads is static. (If cmake forced someone to make that naming decision, so be it, but if someone purposefully chose that name, that was really unfortunate. Tacking on 'tatic' would have killed you?)

Anyway, we only build dynamic on Linux and MacOS, everything else is static, so externals/bundles/pcre/7.6/CMakeLists.txt  goes ahead and does a 

set(PCRE_FOUND "${PCRE_INSTALL_LOC}/lib/libpcre.a")

for anything that builds the external, rather than relying on the system/"proper" target. 

For the mac, it sets PCRE_FOUND to be the .dylib version. 

PCRE_FOUND is used as the link target in classad (the dynamic version) and inserts the .a where it should have picked up the .so from the system version. 

I disabled a few more externals, finally building with

./configure_uw -DWITH_GLOBUS:BOOL=FALSE -DHAVE_BOINC:BOOL=FALSE -DWITH_VOMS:BOOL=FALSE -DWANT_GLEXEC:BOOL=FALSE -DWITH_POSTGRESQL:BOOL=FALSE -DCLIPPED:BOOL=ON -DWITH_BLAHP:BOOL=FALSE -DWITH_CREAM:BOOL=OFF -DWITH_UNICOREGAHP:BOOL=OFF -DWITH_BOSCO:BOOL=OFF -DWITH_LIBVIRT:BOOL=OFF -DWITH_LIBDELTACLOUD:BOOL=OFF

and I finally hit into the actual Condor code! Yay! I was about 10% in, somewhere in condor_util, when bt kicked me off from compiling on submit-1.chtc (boo! 10 more minutes and I'd be done)

Because I'm trying to actually interactively develop change to condor_ssh_to_job, the idea of using an interactive submit to do the compile sounds pretty terrible. So I'm trying to build on a CSL RHEL5 box, and I'm getting hung up on SSL and krb5 detection. 

It's again apparently not using the external version, but wants to use the system version. 

For some reason, find_multiple seems to be failing when called from the externals, but working ConfigureCondor.cmake

For example, in  build/cmake/ConfigureCondor.cmake, there's a:

find_multiple( "ldap;lber" LDAP_FOUND )

and it works:

-- DEBUG: searching[2]:(ldap;lber) ... found[2]:(/usr/lib64/libldap.so;/usr/lib64/liblber.so)

but in externals/bundles/krb5/1.4.3-p1/CMakeLists.txt, nearly the exact same thing:

find_multiple( "krb5;com_err;k5crypto;krb5support;gssapi_krb5" KRB5_FOUND )

Could not find libs(krb5;com_err;k5crypto;krb5support;gssapi_krb5)

but yet:

d-101(85)% ls -l /usr/lib64/libkrb5.so

lrwxrwxrwx 1 root root 14 Feb 29  2012 /usr/lib64/libkrb5.so -> libkrb5.so.3.3

d-101(86)% ls -l /usr/lib64/libkrb5.so.3.3 

-rwxr-xr-x 1 root root 613928 Dec 27  2011 /usr/lib64/libkrb5.so.3.3

However, the krb5 find_multiple works just find on submit-1.chtc and on a CSL RHEL6 machine

find_multiple is just a macro around find_library - is there some state that might be unset once the external CMakeLists are called? I'm confused as to why Condor can find ldap but not krb or openssl. 

(From reading around the web, it sounds like find_library DOESN'T try to compile a test program and link it, ie find_library and find_file are basically the same thing, so if there's some unsatisfied link dependency in the ssl or krb5 libraries that's not the issue. I might be wrong about this, though)

-Erik

On Sun, Mar 24, 2013 at 6:33 PM, Erik Paulson <epaulson@xxxxxxxxxxxx> wrote:

Let's try this again, without hitting send while trying to flip through tabs.

I'm trying to build HTCondor on a Linux machine without the pcre-devel RPM installed. On Linux, this is a problem because HTCondor assumes the system pcre is to be used, not the external. 

<...>