wxruby-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Wxruby-dev] Re: MinGW build


From: Gour
Subject: [Wxruby-dev] Re: MinGW build
Date: Tue, 29 Jul 2003 12:54:33 +0200
User-agent: Mutt/1.4i

Hi!

Please don't think I've been lazy with wxruby since I didn't post anything. My
hands were full of work trying to understand problems with MinGW build.

I even compiled wxWindows with Borland's free 5.5 compiler and did
cross-compiling from my Linux box to Mingw32.

Here is the result of my "investigation".

It looks that the problems Roy (me too) was experiencing was due to my mistake
of trying to link oranges with apples, ie. in the wxWindows documentation it is
written (this fact is also confirmed in many messages I Googled on the way :-)
that with MinGW compiler one needs to use "--disable-shared" switch which
produces (on my system) static library named: wxmsw241.a.  

The problem arises when we use -DWXUSINGDLL=1, since then it is expected to
use DLL version of wxWindows and therefore so much unresolved references during
the linking phase. 

OTOH, compiling WITHOUT -DWXUSINGDLL=1 was failing with strange errors.

The most strange thing is that I am not aware what I did in the first place to 
have
wxruby.so built when trying out different samples, so I wiped out all the 
traces of 
wxWindows on my box and started from the scratch.

So far, I can report that with the following "patch" it is possible to build 
wxruby.so IF the wxWindows are built WITH "--enable-shared" switch when running
configure. This produces (on my system) two libraries: wxmsw241.dll & 
wxmsw241.dll.a,
plus two other copies:

gaura:/home/ggd/win/MinGW/lib # ls -al wx*
-rw-r--r--    1 ggd      users     6462822 Srp 28 12:54 wxmsw241.dll
-rw-r--r--    1 ggd      users    11407326 Srp 28 12:54 wxmsw241.dll.a

gaura:/home/ggd/win/MinGW/lib # ls -al  libwx*
-rw-r--r--    1 ggd      users     6462822 Srp 28 12:54 libwx_msw-2.4.dll
-rw-r--r--    1 ggd      users     6462822 Srp 28 12:54 libwx_msw-2.4.dll.0
-rw-r--r--    1 ggd      users    13331252 Srp 25 13:02 libwxmsw241.a
gaura:/home/ggd/win/MinGW/lib #

(here you can also see static library produced with "--disable-shared" switch)

I was not able to build wxruby with static version of wxWindows library.

Being ignorant about the Windows library mechanism, I am also not sure whether 
it is
possible to build shared library (wxruby.so) by using static wxWindows library.

Here is the "patch" which enables MinGW build with DLL version of wxWindows:

*** extconf.rb  Tue Jul 29 12:34:50 2003
--- /home/ggd/cvs/wxruby/src/extconf.rb Tue Jul 29 12:37:00 2003
***************
*** 24,30 ****
      $LDFLAGS += " `wx-config --libs` -Wl,--version-script,./version-script "
  elsif /mingw32/ =~ RUBY_PLATFORM
!     CONFIG["CC"] = "c++"
!     CONFIG["LDSHARED"].gsub!("gcc","c++")
!     $CFLAGS += " `wx-config --cxxflags`"
      $LDFLAGS += " `wx-config --libs` -Wl,--version-script,./version-script "
      $LIBS += " -lwxmsw241"
--- 24,30 ----
      $LDFLAGS += " `wx-config --libs` -Wl,--version-script,./version-script "
  elsif /mingw32/ =~ RUBY_PLATFORM
!     CONFIG["CC"] = " `wx-config --cxx`"
!     CONFIG["LDSHARED"].gsub!("gcc"," `wx-config --cxx`".strip)
!     $CFLAGS += " `wx-config --cxxflags` -DWXUSINGDLL=1"
      $LDFLAGS += " `wx-config --libs` -Wl,--version-script,./version-script "
      $LIBS += " -lwxmsw241"

As yo ucan see, I explicitly put assignment in CONFIG parameters since backtick
mechanism is not working properly under MSYS. (I'll investigate it further and 
try to
fix it.) 

WXUSINGDLL=1 is not required since it is contained in `wx-config --cxxflags', 
but it
was "required" for compiling when we tried with static version of wxWindows.

Still, there is one mystery ..

I assume that wx-config mechanism should in MinGW & MSYS environment provides 
correct
parameters for compiling and linking, but it does not.

I also recently saw a message from Guy Decouy on Ruby-talk mailing list:

<quote>
Y> I just put preview4 archive on the ftp server.

 This change is normal (in mkmf.rb)

    1.6.8

DLDFLAGS = #{$DLDFLAGS} #{$LDFLAGS}

    1.8.0

DLDFLAGS = #{CONFIG['DLDFLAGS']} #$DLDFLAGS

 If someone use $LDFLAGS in extconf.rb, he'll have surprise with 1.8.0


Guy Decoux
</quote>


The point is that $LDFLAGS is not used in Makefile ($DLDFLAGS is used instead, 
but even
with assigning to $LDFLAGS, required library is not passed to the linker)
and it contains `wx-config --libs`, which gives on my system:

$ wx-config --libs    
-LC:/MinGW/lib -Wl,--subsystem,windows -mwindows -mthreads -lwxmsw241

i.e. it contains required "-lwxmsw241" library for linking but the library is 
not 
passed to the linker and it needs to be added to $LIBS.

The only difference between static & shared version of `wx-config --cxxflags` 
is in
WXUSINGDLL=1 and it explains why the compile was OK, but it failed on linking 
because of
unresolved references.

However, I don't understand why it is not possible to compile the code without
WXUSINGDLL=1 and we get strange errors:

$ make
g++ -g -O2  `wx-config --cxxflags`  -I. -IC:/MINGW/lib/ruby/1.8/i386-mingw32 
-IC:/MINGW/lib/ruby/1.8/i386-mingw32 -I.   -c wx.cpp
g++ -g -O2  `wx-config --cxxflags`  -I. -IC:/MINGW/lib/ruby/1.8/i386-mingw32 
-IC:/MINGW/lib/ruby/1.8/i386-mingw32 -I.   -c app.cpp
In file included from app.cpp:25:
app.h:36:33: macro "Yield" passed 1 arguments, but takes just 0
In file included from app.cpp:25:
app.h:36: variable or field `Yield' declared void
app.cpp: In static member function `static VALUE WxApp::GetClassNameA(long 
   unsigned int)':
app.cpp:174: no matching function for call to `wxAppWithCallbacks::
   GetClassNameA()'
app.cpp:197:29: macro "Yield" passed 1 arguments, but takes just 0
app.cpp: At global scope:
app.cpp:198: syntax error before `{' token
app.cpp:200: syntax error before `->' token
app.cpp: In constructor `WxApp::ZAutoDefineWxApp::ZAutoDefineWxApp()':
app.cpp:209: parse error before `;' token
make: *** [app.o] Error 1


It looks like wxruby.so must be linked with DLL version of wxWindows.

Can someone, please, explain why is it so?

All in all, I learnt something and we'll try to fix and/or improve extconf.rb, 
but we
are still not released 0.1 alpha, so there is still time for improving :-)

The next few days, starting from 31st, I'll be absent from the town and
probably come back around 5th, so maybe I'll miss 1st alpha release.

Good luck !
 
Sincerely,
Gour

-- 
Gour 
address@hidden 
Registered Linux User #278493






reply via email to

[Prev in Thread] Current Thread [Next in Thread]