Re: upgrading from 2006 snapshot to apr-1.3.x

[Bob Rossi]

On Sat, May 17, 2008 at 01:08:59PM +1000, Bojan Smojver wrote:
> On Fri, 2008-05-16 at 22:43 -0400, Bob Rossi wrote:
> 
> > I just upgraded to the 1.3 svn snapshot, to test out the new
> > functionality that was recently added. After I ran my unit tests I
> > noticed that the function apr_dbd_init() was not working properly for
> > me. Then I realized it's because this code,
> 
> With 1.3.x and above, we build DBD modules as DSOs. Did they get built
> properly?

Huh, I build with --disable-shared --enable-static. Perhaps it doesn't
work in this configuration? I do see, 

  $ ls apr-util-1.3.x-2008-05-16-cvs/
  bin  include  lib

  $ ls apr-util-1.3.x-2008-05-16-cvs/lib
  apr-util-1  aprutil.exp  libaprutil-1.a  libaprutil-1.la  pkgconfig

  $ ls apr-util-1.3.x-2008-05-16-cvs/lib/apr-util-1/
  apr_dbd_pgsql.a  apr_dbd_pgsql.la  apr_dbd_sqlite3.a
  apr_dbd_sqlite3.la

I'm thinking perhaps this doesn't work with --disable-shared. If I set a
breakpoing in 
  APU_DECLARE(apr_status_t) apr_dbd_get_driver(apr_pool_t *pool,
    const char *name, const apr_dbd_driver_t **driver)
I can see that it does this,
  apr_snprintf(path, sizeof path, "%s/apr_dbd_%s.so", APU_DSO_LIBDIR, name);

There is a couple of disturbing things here, for starters, the "path"
variable declared on the stack is hard coded to a certain size,

  char path[80];

my installation of apr-util is this long (in this circumstance)
  echo $PWD|wc -c
  120

I realy think that variable should be dynamic. ie. the length of 
  APU_DSO_LIBDIR + 
  1 for '/' + 
  8 for "apr_dbd_" +
  name +
  3 for .so +
  1 for NULL

since that is the longest possible name, that should cover the rest of
the cases.

So, it seems like there is 2 bugs here perhaps? Doesn't work with
--disable-shared and the path variable is to small on the stack.

Thanks,
Bob Rossi