Quoting Mike Pape <[EMAIL PROTECTED]>:
> I also used a different libtool (from gnuwin32) instead of building the
> latest to save time.
Building the libtool takes about 5% of the time of building subversion, so
this shouldn't hinder you.
> As for building subversion, that was the hardest part. I built zlib, apr,
> apr-util, and neon separately with minor tweaks to the LDFLAGS so that I
> wasn't getting static linking. I installed each one as it was built.
I thought LDFLAGS="-no-undefined" was the most important part that
switched to
shared libraries. All other LDFLAGS parts shouldn't influence the static vs.
shared decision.
The problem was things like building apr-util complained of undefined
references to apr pieces. Did you build all the deps from the
subversion directory or each dep by itself?
For a long time I saw "undefined references" to apr pieces when
building apr-util. Eventually I could resolve all of them so that I
really got all subversion pieces by one ./autogen.sh; ./configure ...;
make ..., so I think I did what you referred to as "all deps from the
subversion directory".
These were the things I did to resolve them:
* Check whether apr was build as DLL, i.e. the file
apr/.libs/libapr-0-0.dll and the corresponding import library
libapr-0.dll.a (or similar) exists. If not, it means the shared
library building of apr failed in the first place and that has to be
solved first.
* If libapr-0-0.dll is there, check whether the complained undefined
references actually exist in libapr. For example, the linker error
said "undefined reference to apr_foo_bar", then I'd do
nm apr/.libs/libapr-0-0.dll | grep apr_foo_bar
or
nm apr/.libs/libapr-0.dll.a | grep apr_foo_bar
If this exists, the error is most probably due to missing -L and
-lapr flags when the apr-util linker command is called and you can add
more LDFLAGS or LIBS to the "make" call. If this doesn't exist, there
probably was an error at compilier libapr-0-0.dll. Usually I always
encountered the first problem.
Christian
