Re: libtool compilation failures (ITS#795)

[bcollins@debian.org]

On Mon, Oct 02, 2000 at 07:10:32PM +0000, jlittle@open-it.org wrote:
> I agree about mucking with the build system.
> 
> To recap:
> 
> openldap 2.0.4 builds normally on a system with or without the libtool
> package being installed. However, if libtoolize is called previous to
> running configure (which rpm and other programs do), the purported purpose
> is to check the /build tree and generate libtool before configure (whereas
> configure will attempt to do it itself if libtoolize has not been
> run). The problem stems from the fact that libtoolize creates a different
> libtool than that packaged with openldap 2.0.4 (libtool 1.3.3) whereas
> openldap 1.2.x creates a one at harmony with system definitions. the
> openldap 2.0.4 version conflicts with the system libtool definitions in
> the arguments it accepts. 

No, the reason RPM does this is to install it's own version of a RedHat
policy libtool. It wants things to built "it's way". This is wrong for
RPM to do by default and without any way to override. It is not right, it
is Very Bad no matter how you look at it. No other programs do this.

Let's say I build a program that has a file called "ltmain.sh" that is not
really part of libtool, but I created it to be similar. RPM will
completely break on building my program.

You see the point here? Not that this case would ever happen, but it can,
and the developer of the software is free to do that. Distribution
packages are not at liberty to make such assumptions.

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'