Hi, On Thu, 31 Jan 2008, Mike Pape wrote:
> 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. > > 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. Thanks. I was a little overloaded at work (and working on Windows always takes twice as long), so I planned to do some work on it tonight, or tomorrow. But this is great: coming back to reading emails and finding that others have done all the hard work ;-) FWIW we have the convention now that every ref that is in the work/ namespace is subject to rebasing/scrapping. And if you want to say that you don't want others to touch it, put it in <name>/<ref>. IMO the mob branch should be the way to contribute for new developers who do not want to fork (yet). Will have a look, Dscho
