On Jan 31, 2008 9:45 AM, Christian Stimming <[EMAIL PROTECTED]> wrote: > 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 >
I didn't notice your patch on the mob branch. That worked like a charm except for one patch I needed. Building neon crapped out because of its regex symbol export. libtool created a situation where it was piping to no command. Not sure if you had anything like that. Dscho, I pushed my patch for neon as well as building libtool, shared zlib, and swig to mob instead of temp/msys. It's been a while since I've pushed anything to the repo, so I thought I'd let you review before merging. Mike
