Daniel Stenberg wrote:
>
> I think the problem is that somehow, due to the src.rpm building process, the
> build system thinks it needs to run 'libtoolize' and then it finds itself in
> some kind of conflict. I mean, since it builds perfectly well from the tar.gz
> archive, something must have been changed when it was "converted".

Yah, yah -- looking in the RPM 'macros' file, I see that it's run as a
part of the %configure macro (you run %configure instead of ./configure,
and it automagically adds all the roght --prefix, --exec-prefix, etc
flags). Here's the snippet:

# This is an improved version of %configure (from PLD team).
%configure \
CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
%{?__libtoolize:[ -f configure.in ] && %{__libtoolize} --copy --force} ;
\
./configure %{_target_platform} \\\
        --prefix=%{_prefix} \\
[blah blah blah blah more junk]

So, it would appear to me that if a file 'configure.in' is present, it
will run libtoolize? Let's put that to a test....

Well, it stops the libtoolize process (if I rm -f configure.in before
%configure), but then breaks the make process:

+ make
make: *** No rule to make target `configure.in', needed by
`Makefile.in'. Stop.

Maybe if we just move it out of the way, then move it back? Let's take a
look... yup! that will appear to do the trick, if it's acceptable (does
./configure need configure.in for anything? don't think so). My build
section would then look like:

%build
cd %{curlroot} && (if [ -f configure.in ]; then mv -f configure.in
configure.in.rpm; fi)
%configure --without-ssl
cd %{curlroot} && (if [ -f configure.in.rpm ]; then mv -f
configure.in.rpm configure.in; fi)
make

-te

-- 
Troy Engel :: KeyID DF3D5207
<DragonGrl> It's not just the bod, it's the kernel. (;