Re: [lmi] synchronizing wx and lmi for production

[Vadim Zeitlin]

On Fri, 12 Aug 2005 16:00:58 -0400 "Boutin, Wendy" <address@hidden> wrote:

BW> I'm behind a firewall in the office, so when I try to checkout new
BW> wx code my issues seem to stem from that firewall not liking 'pserver';

 Hello,

 unfortunately I don't know what to do about it -- wx cvs server currently
only provides pserver access and although I think that dotsrc (ex-SunSite.dk)
admins do plan to provide it, I have no idea when would it happen. You can,
of course, write them (http://dotsrc.org/) to ask about it, if they plan to
do it soon maybe the problem will just go away on its own.

BW> Have you come across this problem before?

 Yes but there is just no way to solve it that I know. What I usually do
when I'm behind a pserver-allergic firewall is to ssh to my machine, do
"cvs co" from there, tar it up and then scp the file. Not really useful...

BW> At times I've resorted to using wx's nightly tarballs for testing.
BW> The problem with that method is the archives are only available on
BW> the server for seven days. In our business environment, it takes
BW> longer than those seven days to test, accept, and then release your
BW> changes to others for a formal upgrade and synchronization with lmi.

 I think it's best to make available the latest wx version tested
with/acceptable for lmi separately anyhow.

BW> Although, the bigger problem is not having a stable URL that can be
BW> used in our setup automation.

 Hmm, what about http://biolpc22.york.ac.uk/pub/CVS_HEAD/wx-cvs-All.tar.bz2
? I admit I haven't really ever used it but this URL seems to be quite
permanent.

BW> While we're on the subject, I've often just used the most recent cvs
BW> when testing your enhancements for us--sometimes its been days before
BW> I got to the testing. Should I be using cvs as of some specific date
BW> after you've fixed something?

 No, I don't think so. The current wx cvs HEAD (which will become 2.6
branch very soon) is very stable, it is almost never broken so I think you
can try it any moment.

BW> That aside, I've been attempting to build wx using ./configure && make
BW> in msys in lieu of manually modifying setup.h. Unfortunately, the usual
BW> libraries I expect aren't all there, so I'm guessing I've probably
BW> missed something. I'm pretty sure I correctly translated the settings
BW> I want on the command line, but I don't really know what else I may
...
BW> and make it this way:
BW>   make --keep-going -f makefile.gcc SHARED=1 MONOLITHIC=1 USE_THREADS=0 \
BW>   CXXFLAGS="-DNO_GCC_PRAGMA"
BW> 
BW> which results in these libraries:
BW>   [hidden] /c/downloads/wxWidgets-2.5.4/lib/gcc_dll
BW>   $ ls
BW>   libwxexpatd.a  libwxpngd.a    libwxzlibd.a
BW>   libwxjpegd.a   libwxregexd.a  mswd
BW>   libwxmsw25d.a  libwxtiffd.a   wxmsw254d_gcc_custom.dll

 Yes, this looks correctly for MONOLITHIC=1.

BW> I got these warnings, but they didn't seem detrimental:
BW>   configure: WARNING: system regex library not found, will use built-in 
instead
BW>   configure: WARNING: zlib library not found or too old, will use built-in 
instead
BW>   configure: WARNING: system png library not found or too old, will use 
built-in instead
BW>   configure: WARNING: system expat library not found, will use built-in 
instead
BW>   configure: WARNING: ddraw.h or multimon.h not found; disabling wxDisplay
BW>   configure: WARNING: ddraw.h or multimon.h not found; disabling wxDisplay
BW>   configure: WARNING: Catching fatal exceptions not currently supported on 
this system, wxApp::OnFatalException will not be called

 No, all of these warnings are harmless (and expected).

BW> and made it this way:
BW>   make >>buildlog 2>&1
BW> 
BW> but that resulted in only these libraries:
BW>   [hidden] /c/downloads/wxWidgets/build-msys/lib
BW>   $ ls
BW>   libwxexpat-2.6.a  libwxpng-2.6.a  libwxregex-2.6.a  libwxzlib-2.6.a  wx

 This is mysterious. Are you sure your linker didn't die with out of memory
message or something like that? GNU ld does have a nice habit of requiring
up to 500Mb of RAM to link big DLLs. If lack of RAM is really a problem,
you might try to build without --enable-monolithic: then the DLLs would be
smaller. Another possibility is that you ran out of disk space as you may
need up to 1GB of it to build wx (this is for debug build though, in
release it is much less fat).

 I really don't know what else could be a problem here because in theory
you're, of course, suppose to get wxmsw26_gcc_custom.dll and the import
library libwxmsw26_gcc_custom.dll.a. Please try running "make" again
without redirecting its output, you should see that it tries to create the
DLL -- and fails for whatever reason.

 Good luck!
VZ