msys, wx 2.8.0, gcc, linking phase problem

[Daniel C. Bastos]

In article <8b2dneJKQ_jSllPYnZ2dnUVZ_qemnZ2d at insightbb.com>,
John Ratliff wrote:

> Daniel C. Bastos wrote:
> > In article <fLmdnX1IKf8dllDYnZ2dnUVZ_ofinZ2d at insightbb.com>,
> > John Ratliff wrote:
> > 
> >> Daniel C. Bastos wrote:
> > 
> > [...]
> > 
> >>> Using the microsoft free compiler wouldn't be a bad idea at all, since
> >>> it seems to generate smaller executable sizes for GUI applications --- I
> >>> read that somewhere on the web. Is it true?
> >> Microsoft's VC++ compiler has typically produced smaller executables 
> >> than mingw-gcc, so if you're fond of VC++, I'd say use it.
> > 
> > I'm not too fond of VC++. I'd like to use the GNU emacs and just call
> > the cl.exe compiler; but right now, when I call it under msys, I get a
> > message box with title ``cl.exe - Unable to Locate Component'' and
> > content ``This application has failed to start because mspdb80.dll was
> > not found. Re-installing the application may fix this problem.'' and
> > finally an ``OK'' button to be pressed.
> > 
> > When I run cl.exe through the cmd.exe shell, I also get the same message
> > box. So the problem is not particular to msys. 
> > 
> > The file mspdb80.dll exists in these directories:
> > 
> > C:\sdk\Bin\win64
> > C:\Program Files\Microsoft Visual Studio 8\Common7\IDE
> > c:\sdk\bin\win64\x86\AMD64
> > 
> > and in no other.
> > 
> > Do you know how can I instruct cl.exe to find its DLLs?
> 
> It may be difficult to use Microsoft's compiler under msys since /bin/sh 
> is expecting / path delimiters while cl will be expecting \. Sometimes 
> it works, and sometimes it doesn't.
> 
> It would be better to sick with cmd.exe if you want to use cl on the 
> command line.

Hm. I see.

[...]

> >> As for msys, I've never compiled the 2.8 version as I haven't tried it 
> >> yet, but when I compile in msys (e.g. version 2.6.3), I do the following:
> >>
> >> /c/wxWidgets-2.6.3/configure --disable-debug --disable-compat24 
> >> --disable-shared --disable-unicode --enable-optimise 
> >> --prefix=/usr/local/wx/2.6.3/sra &> configure.log
> >> make && make install
> >>
> >> What did you use for your configure line?
> > 
> > I did
> > 
> > cd builddebug
> > ../configure --enable-debug --enable-debug_gdb --with-msw
> 
> I tried your options and I don't run into any problems. What version of 
> gcc are you using? What about win32api?

%g++ --version
g++.exe (GCC) 3.2.3 (mingw special 20030504-1)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

How can I look up my win32 api version? I installed some PSDK package
from a Microsoft website. The release notes of the SDK says ``Windows
Server 2003 R2 Platform SDK.'' It was installing this package that I was
able to have a windows.h, for instance.

> > I'm going to try your options. I appreciate your help.
> > 
> > %mkdir ratliff
> > %cd ratliff
> > %../configure --disable-debug --disable-compat24 --disable-shared --disable-uni
> > code --enable-optimise --prefix=/usr/local/wx/2.8.0 &> configure.log
> > 
> > Now it worked. 
> 
> If you using debug mode, you should really use shared libraries. It 
> takes forever to link a program with static debug libraries.

Okay.

> For me, I keep several versions of wx compiled at all times. I use 
> static release ansi mode most of the time. Then I have a static release 
> unicode build to make sure my program will work under unicode. Then if I 
> run into any problems that need debugging, I have a shared debug ansi 
> build so I can run gdb.

This sounds good. I'm doing that too now.

> >  ------------------------------------------------------
> > 
> >  The installation of wxWidgets is finished.  On certain
> >  platforms (e.g. Linux) you'll now have to run ldconfig
> >  if you installed a shared library and also modify the
> >  LD_LIBRARY_PATH (or equivalent) environment variable.
> >  
> >  wxWidgets comes with no guarantees and doesn't claim
> >  to be suitable for any purpose.
> >  
> >  Read the wxWidgets Licence on licencing conditions.
> >  
> >  ------------------------------------------------------
> > 
> > Previously, the problem seemed to be the generation of a custom dll for
> > gcc; now that I said ``--disable-shared'' to try your options, it
> > worked; so the fact that now worked with --disable-shared says that
> > there could be something not portable enough in the generation of the
> > shared library --- at least for gcc, as it seems to be the case.
> > 
> > Since my errors are undefined references, it could be as simple as the
> > forgetting of some object files in the dll generation phase. I don't
> > know any easy way to spot where exactly the problem is, though. But I
> > can be used as an operator to track the problem; just let me know,
> > whoever would like to investigate.
> 
> Like I said, your options worked fine for me, so I'm not sure where the 
> problem lies.
> 
> I'd like to know more about your mingw and msys installation. What 
> versions are you running?

Here's my msysinfo output.

%msysinfo 
msysinfo-1.3: Send this to the MSYS support list:

MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 3.2.3 (mingw special 20030504-1); targ=MINGW32
GNU ld version 2.13.90 20030111
   789320 Tue Mar 16 13:32:49 2004 /bin/msys-1.0.dll
   135680 Tue Mar 16 13:32:48 2004 /usr/bin/make.exe
    82432 Sun May 04 23:38:20 2003 /mingw/bin/gcc.exe
   566272 Sun Jan 12 04:42:48 2003 /mingw/bin/ld.exe
HOME=/home/Daniel
Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=msys
PATH=~/bin/:/usr/bin:/usr/local/bin/:/usr/local/noweb:.:/usr/loc
al/bin:/mingw/bin:/bin:/c/Program Files/PHP/:/c/texmf/miktex/bin
:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Prog
ram Files/ATI Technologies/ATI Control Panel:/c/Program Files/Co
mmon Files/Roxio Shared/DLLShared/:/c/ispell/bin:/c/Program File
s/Microsoft Command Shell/v1.0/:/mingw/bin:/c/emacs/bin:/c/cygwi
n/bin:/c/cygwin/usr/local/bin:/c/Program Files/MySQL/MySQL Serve
r 5.0/bin:/c/Program Files/Microsoft Visual Studio 8/VC/bin:/c/P
rogram Files/Wormux 0.7/bin
$ ls -tx /home/Daniel
.bash_history  .emacs      .emacs.~3~  wri/  .emacs.~2~
sft/           .emacs.~1~  .profile    bin/  .emacs.d/
.history

%g++ --version
g++.exe (GCC) 3.2.3 (mingw special 20030504-1)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

%ld --version
GNU ld version 2.13.90 20030111
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

I've working with wxWidgets 2.8.0 --- the .exe package from the website;
no CVS version. By the way, I was able to build it fixing every linking
error in the way that I described in my thread with Vadim Zeitlin.