[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dynamic executables for check_PROGRAMS?

From: John Calcote
Subject: Re: dynamic executables for check_PROGRAMS?
Date: Thu, 17 Feb 2011 17:31:52 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7

Hi Jeff,

On 02/17/2011 04:06 PM, Daily, Jeff A wrote:
> I wrote a profiling layer for my library utilizing weak symbols.  I thought 
> for starters it would be nice to profile some of my test programs, to make 
> sure things are working okay.  I'm using autoconf, automake, and libtool, so 
> I configured using --enable-shared --disable-static, however, my test 
> programs are not created as dynamic executables.  If I change my 
> check_PROGRAMS to bin_PROGRAMS, they are dynamic executables.  But, I can't 
> do this in production for obvious reasons.
> So, is there any way to create dynamic executables for my check_PROGRAMS?
> Jeff

The --enable/disable-static/shared flags apply only to building shared
or static libraries within your project. These flags don't have anything
to do with how executables are built except to limit or expand the
options available to programs built against internal libraries. To test
this assertion, create a simple project without libtool (don't call
LT_INIT in When you run ./configure --help, you'll see
that these options are missing entirely from the help display.

I assume when you say "dynamic executables" you're referring to test
programs built to use shared libraries created from within the same
project. If you're noticing that your test binaries are getting linked
against your static libraries, then something strange is happening in
your project: If you're using --disable-static and it's working proper
but your check_PROGRAMS are inclined to link with the (now non-existent)
static libraries then I have to ask: How are these static libraries
getting built? - After all, you disabled them.

Assuming you've got code like this:

   check_PROGRAMS = test1
   test_SOURCES = test1.c
   test_LDADD = ../mylib/

Make sure test_LDADD is referring to the correct relative path to your
internally built .la file. If you're specifying mylib.a (or even without a relative path, you may be picking up a static
version of your library from your environment (/usr/lib or /usr/local/lib).

My assumptions may all be wrong - especially in light of the fact that
bin_PROGRAMS seems to work the way you want it to...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]