[Top][All Lists]

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

Re: where libltdl will be libtoolized

From: Bob Friesenhahn
Subject: Re: where libltdl will be libtoolized
Date: Fri, 19 Nov 2004 14:35:19 -0600 (CST)

On Fri, 19 Nov 2004, Ralf Wildenhues wrote:

Current state of libtldl branch-2-0 is inconsistent:
 libtoolize --ltdl=some/sub/dir

will not work.  The include paths in ltdl.h
| ltdl.h:#include <libltdl/lt_system.h>
| ltdl.h:#include <libltdl/lt_error.h>
| ltdl.h:#include <libltdl/lt_dlloader.h>

Oh, dear!!!

The package I maintain puts libltdl files in the directory 'ltdl' rather than 'libltdl' and I expect to keep things that way (we still use CVS). It seems wrong for libltdl files to make assumptions regarding the directory they reside in.

and libltdl/'s
| AM_CPPFLAGS             = -I$(top_builddir) -I$(top_srcdir)

will conflict in a package which uses libltdl.

Yes, and it will not work if libltdl files are under "foo/libltdl". It is a bad idea to assume where the libltdl files will be located. If the libltdl build needs to know, and it can't find out for itself, then the "user" ( should be required to specify where the libltdl files reside.

We have to decide: Either the `libtoolize --ltdl' argument must
end in `libltdl', or we need to provide a flat directory structure.
(Note that this stems from the requirement to be able to either use
an installed libltdl or a package-internal one, with the repective other
one absent).

A flat directory structure (as we had before) sounds good to me. I do not plan to actually use libltdl's to build libltdl since that would require that the build is recursive and my package does not use a recursive build anymore. I do/did plan to see if libltdl's files can be adapted to serve either purpose (supporting non-recursive build via Automake includes) but I have not had time for that yet.

Libltdl's new complex build scheme has been worrying me.

I like the former better for several reasons:
- better forward compatibility from 1.5 (maybe)
- supposedly less trouble when within a larger collection of
- People much rather like to bury autotools in some directory
 structure whose top they decide and the innards they could care less.

Anybody know packages using libltdl with a different strategy already
(which would then conflict)?

So, OK to apply this patch?

Doesn't the config.h header still pose problems?  I think not but am not
so sure.

I see code in argz.c that looks like it could be a problem. Maybe it wasn't updated the same way as other source files?

Bob Friesenhahn

reply via email to

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