[wxOSX] Build Broken
Jeff Tupper
Intel, the build stops with the following:
(The build is for Carbon; I haven't tried Cocoa with this revision.)
/Users/tupper/dev/wxWidgets/osx-carbon-build/bk-deps g++ -mmacosx-
version-min=10.4 -c -o wxrc_wxrc.o -D__WXOSX_CARBON__ -I../../../
utils/wxrc -DwxUSE_GUI=0 -Wall -Wundef -Wunused-parameter -Wno-ctor-
dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations -
D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -I/Users/tupper/dev/wxWidgets/
osx-carbon-build/lib/wx/include/osx_carbon-unicode-static-2.9 -
I../../../include -fpascal-strings -I/Developer/Headers/FlatCarbon -
DWX_PRECOMP -O2 -fno-strict-aliasing -fno-common ../../../utils/wxrc/
wxrc.cpp
g++ -mmacosx-version-min=10.4 -o wxrc wxrc_wxrc.o -L/Users/tupper/
dev/wxWidgets/osx-carbon-build/lib -framework IOKit -framework Carbon
-framework Cocoa -framework AudioToolbox -framework System -framework
OpenGL -framework QuickTime -lexpat -lwx_osx_carbonu-2.9 -
lwxregexu-2.9 -framework IOKit -framework Carbon -framework Cocoa -
framework AudioToolbox -framework System -framework OpenGL -framework
QuickTime -lz -lpthread -framework WebKit -lz -lpthread
Undefined symbols:
"_png_read_image", referenced from:
wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
"_png_write_end", referenced from:
wxPNGHandler::SaveFile(wxImage*, wxOutputStream&, bool) in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
"_png_set_pHYs", referenced from:
wxPNGHandler::SaveFile(wxImage*, wxOutputStream&, bool) in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
"_png_set_sBIT", referenced from:
wxPNGHandler::SaveFile(wxImage*, wxOutputStream&, bool) in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
"_png_get_header_version", referenced from:
wxPNGHandler::GetLibraryVersionInfo() in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
"_png_read_info", referenced from:
wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
"_png_set_compression_buffer_size", referenced from:
wxPNGHandler::SaveFile(wxImage*, wxOutputStream&, bool) in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
.
.
.
2.9.a(monolib_imagpng.o)
"_png_get_io_ptr", referenced from:
_wx_PNG_stream_reader in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
_wx_PNG_stream_writer in
libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
_wx_png_warning in libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
_wx_png_error in libwx_osx_carbonu-2.9.a(monolib_imagpng.o)
ld: symbol(s) not found
Configuration: -disable-shared --disable-debug --enable-optimise --
disable-no_rtti --disable-no_exceptions --disable-compat28 --disable-
mdi --with-opengl --enable-monolithic --enable-unicode --disable-utf8
--enable-stl --disable-printfposparam --with-macosx-version-min=10.4 --
with-libiconv=no
Jeff Tupper
> When I build wxOSX trunk (revision 66528 today) on OS X 10.5.8 /
> Intel, the build stops with the following:
Vadim Zeitlin
JT> g++ -mmacosx-version-min=10.4 -o wxrc wxrc_wxrc.o -L/Users/tupper/
JT> dev/wxWidgets/osx-carbon-build/lib -framework IOKit -framework Carbon
JT> -framework Cocoa -framework AudioToolbox -framework System -framework
JT> OpenGL -framework QuickTime -lexpat -lwx_osx_carbonu-2.9 -
JT> lwxregexu-2.9 -framework IOKit -framework Carbon -framework Cocoa -
JT> framework AudioToolbox -framework System -framework OpenGL -framework
JT> QuickTime -lz -lpthread -framework WebKit -lz -lpthread
JT> Undefined symbols:
JT> "_png_read_image", referenced from:
JT> wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)in
...
JT> Configuration: -disable-shared --disable-debug --enable-optimise --
JT> disable-no_rtti --disable-no_exceptions --disable-compat28 --disable-
JT> mdi --with-opengl --enable-monolithic --enable-unicode --disable-utf8
JT> --enable-stl --disable-printfposparam --with-macosx-version-min=10.4 --
JT> with-libiconv=no
I assume this is specific to monolithic build, right? Also, are you using
the built-in libpng or the system one?
Finally, do you remember what was the last working version by chance?
Thanks,
VZ
Jeff Tupper
>
> JT> g++ -mmacosx-version-min=10.4 -o wxrc wxrc_wxrc.o -L/Users/tupper/
> JT> dev/wxWidgets/osx-carbon-build/lib -framework IOKit -framework Carbon
> JT> -framework Cocoa -framework AudioToolbox -framework System -framework
> JT> OpenGL -framework QuickTime -lexpat -lwx_osx_carbonu-2.9 -
> JT> lwxregexu-2.9 -framework IOKit -framework Carbon -framework Cocoa -
> JT> framework AudioToolbox -framework System -framework OpenGL -framework
> JT> QuickTime -lz -lpthread -framework WebKit -lz -lpthread
> JT> Undefined symbols:
> JT> "_png_read_image", referenced from:
> JT> wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)in
> ...
> JT> Configuration: -disable-shared --disable-debug --enable-optimise --
> JT> disable-no_rtti --disable-no_exceptions --disable-compat28 --disable-
> JT> mdi --with-opengl --enable-monolithic --enable-unicode --disable-utf8
> JT> --enable-stl --disable-printfposparam --with-macosx-version-min=10.4 --
> JT> with-libiconv=no
>
> I assume this is specific to monolithic build, right?
> Also, are you using the built-in libpng or the system one?
open. The following is copied from it:
Which libraries should wxWidgets use?
STL yes
jpeg builtin
png builtin
regex builtin
tiff builtin
zlib sys
expat sys
libmspack no
sdl no
> Finally, do you remember what was the last working version by chance?
here.)
Jeff Tupper
>
> JT> g++ -mmacosx-version-min=10.4 -o wxrc wxrc_wxrc.o -L/Users/tupper/
> JT> dev/wxWidgets/osx-carbon-build/lib -framework IOKit -framework Carbon
> JT> -framework Cocoa -framework AudioToolbox -framework System -framework
> JT> OpenGL -framework QuickTime -lexpat -lwx_osx_carbonu-2.9 -
> JT> lwxregexu-2.9 -framework IOKit -framework Carbon -framework Cocoa -
> JT> framework AudioToolbox -framework System -framework OpenGL -framework
> JT> QuickTime -lz -lpthread -framework WebKit -lz -lpthread
> JT> Undefined symbols:
> JT> "_png_read_image", referenced from:
> JT> wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)in
> ...
> JT> Configuration: -disable-shared --disable-debug --enable-optimise --
> JT> disable-no_rtti --disable-no_exceptions --disable-compat28 --disable-
> JT> mdi --with-opengl --enable-monolithic --enable-unicode --disable-utf8
> JT> --enable-stl --disable-printfposparam --with-macosx-version-min=10.4 --
> JT> with-libiconv=no
>
> I assume this is specific to monolithic build, right?
and everything built OK.
Dimitri Schoolwerth
> On Jan 3, 2:30 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>> On Sun, 2 Jan 2011 17:13:02 -0800 (PST) Jeff Tupper <tupperli...@gmail.com> wrote:
>>
[undefined libpng symbols]
>> I assume this is specific to monolithic build, right?
>
> I've just tried a non-monolithic build along with one of the samples
> and everything built OK.
Then I think you were still also using --disable-shared? Here it does
not occur with just --enable-monolithic but does error with
--disable-shared --enable-monolithic (also just --disable-shared works
OK).
The problem was introduced in r66505 . If I update to r66505 but use
configure @ r66504 then it works fine again. I guess it has something
to do with core's artprovider now having a dependency on libpng when
wxUSE_ARTPROVIDER_TANGO is set to 1? (I hope there's another solution
besides having to use the BMP image handler which is always
available).
Jeff: For now you can use --disable-arttango to circumvent this problem.
Regards,
Dimitri
Vadim Zeitlin
DS> Then I think you were still also using --disable-shared? Here it does
DS> not occur with just --enable-monolithic but does error with
DS> --disable-shared --enable-monolithic (also just --disable-shared works
DS> OK).
DS> The problem was introduced in r66505 . If I update to r66505 but use
DS> configure @ r66504 then it works fine again. I guess it has something
DS> to do with core's artprovider now having a dependency on libpng when
DS> wxUSE_ARTPROVIDER_TANGO is set to 1?
Thanks a lot for looking into this! Unfortunately I still don't understand
how exactly did this break. While we do have a dependency on libpng in this
art provider, we always had a dependency on it in wxPNGHandler itself and
this didn't prevent it from linking before... And if the answer is that
wxPNGHandler wasn't pulled in by the linker when building wxrc at all, I
wonder how is it different for wxTangoArtProvider, after all wxrc is a
console application and shouldn't be using any art providers at all.
Unfortunately I can't reproduce the problem under Linux (in
"--enable-monolithic --enable-arttango --with-libpng=builtin" build) so
I'll need to try it under Mac later to understand what is really going on
here...
Regards,
VZ
Dimitri Schoolwerth
> On Tue, 4 Jan 2011 13:06:34 +0400 Dimitri Schoolwerth <dimitri.s...@gmail.com> wrote:
>
> DS> Then I think you were still also using --disable-shared? Here it does
> DS> not occur with just --enable-monolithic but does error with
> DS> --disable-shared --enable-monolithic (also just --disable-shared works
> DS> OK).
> DS> The problem was introduced in r66505 . If I update to r66505 but use
> DS> configure @ r66504 then it works fine again. I guess it has something
> DS> to do with core's artprovider now having a dependency on libpng when
> DS> wxUSE_ARTPROVIDER_TANGO is set to 1?
>
> Thanks a lot for looking into this! Unfortunately I still don't understand
> how exactly did this break. While we do have a dependency on libpng in this
> art provider, we always had a dependency on it in wxPNGHandler itself and
> this didn't prevent it from linking before... And if the answer is that
> wxPNGHandler wasn't pulled in by the linker when building wxrc at all, I
> wonder how is it different for wxTangoArtProvider, after all wxrc is a
> console application and shouldn't be using any art providers at all.
Hmm, good points. I don't know either right now.
> Unfortunately I can't reproduce the problem under Linux (in
> "--enable-monolithic --enable-arttango --with-libpng=builtin" build) so
> I'll need to try it under Mac later to understand what is really going on
> here...
Did you also try with --disable-shared? --enable-monolithic works fine
here, --disable-shared --enable-monolithic does not (as mentioned
above).
Regards,
Dimitri
Vadim Zeitlin
DS> > Thanks a lot for looking into this! Unfortunately I still don't understand
DS> > how exactly did this break. While we do have a dependency on libpng in this
DS> > art provider, we always had a dependency on it in wxPNGHandler itself and
DS> > this didn't prevent it from linking before... And if the answer is that
DS> > wxPNGHandler wasn't pulled in by the linker when building wxrc at all, I
DS> > wonder how is it different for wxTangoArtProvider, after all wxrc is a
DS> > console application and shouldn't be using any art providers at all.
DS>
DS> Hmm, good points. I don't know either right now.
Ok, I do know it. This is because in fact everything referenced from
wxModule-derived classes always gets linked in (wxModule is explicitly
designed to avoid the linker from discarding it). And all art providers are
referenced from wxArtProviderModule::OnInit().
Unfortunately I still don't know how to fix this. Even if we don't call
InitTangoProvider() from the wxArtProviderModule::OnInit(), we still need
to call it from some InitBuiltInProvidersIfNeeded() function which would be
called by all wxArtProvider methods using the providers. And this set
includes, in particular, GetSizeHint() method which iterates over the
providers stack. And GetSizeHint() is linked as part of even the console
program because it is called from virtual DoGetSizeHint() which, in turn,
is linked in because it is referenced by wxArtProvider vtbl. Which itself
seems to be referenced by g++ as long as we compile artprov.cpp at all.
So I just don't see any good solution. I'm afraid we'll need to link
console programs using monolithic library with libpng to fix this. Which
is, of course, ugly but then you arguably shouldn't be using monolithic
library at all if you want to build non-GUI stuff.
Any better ideas?
DS> > Unfortunately I can't reproduce the problem under Linux (in
DS> > "--enable-monolithic --enable-arttango --with-libpng=builtin" build) so
DS> > I'll need to try it under Mac later to understand what is really going on
DS> > here...
DS>
DS> Did you also try with --disable-shared? --enable-monolithic works fine
DS> here, --disable-shared --enable-monolithic does not (as mentioned
DS> above).
Sorry, this was a bad cut and paste. I did try with --disable-shared.
The real reason it linked for me was that the binary still depended on the
system libpng.so which was pulled in as a dependency of the GTK libraries.
Regards,
VZ
Dimitri Schoolwerth
> On Tue, 4 Jan 2011 15:35:49 +0400 Dimitri Schoolwerth <dimitri.s...@gmail.com> wrote:
>
> So I just don't see any good solution. I'm afraid we'll need to link
> console programs using monolithic library with libpng to fix this. Which
> is, of course, ugly but then you arguably shouldn't be using monolithic
> library at all if you want to build non-GUI stuff.
Because of the latter, and the linking only applying to the monolithic
build, I agree with this.
> Any better ideas?
Probably not better but an alternative for consideration: saving the
Tango icons in another format such as BMP or TGA. It would make the
conversion process to .h more difficult (the Tango PNG files would
have to be decoded and preferably saved with RLE compression). Also
the image sizes will be larger. I just tried saving all Tango Action
icons at 16x16 and 22x22 to TGA RLE, the former increased 30% and the
latter almost 60% in disk size.
Putting those images in a single zlib stream makes them almost 40%
smaller than the original PNG files but this would introduce a zlib
dependency instead of libpng and perhaps it's better to leave
compression of executables to the user (although we also already do it
with the Tango icons now).
BTW: in misc/scripts/png2c.py shouldn't the 2 occurrences of 4096 be
replaced by 65536? (not that it will ever be a problem)
Regards,
Dimitri
Vadim Zeitlin
DS> On Tue, Jan 4, 2011 at 4:31 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
DS> > On Tue, 4 Jan 2011 15:35:49 +0400 Dimitri Schoolwerth <dimitri.s...@gmail.com> wrote:
DS> >
DS> > So I just don't see any good solution. I'm afraid we'll need to link
DS> > console programs using monolithic library with libpng to fix this. Which
DS> > is, of course, ugly but then you arguably shouldn't be using monolithic
DS> > library at all if you want to build non-GUI stuff.
DS>
DS> Because of the latter, and the linking only applying to the monolithic
DS> build, I agree with this.
I've finally done this now (r66848), sorry for the delay.
DS> BTW: in misc/scripts/png2c.py shouldn't the 2 occurrences of 4096 be
DS> replaced by 65536? (not that it will ever be a problem)
Oops, yes, of course, thanks for noticing it, fixed (even though I agree
that it probably isn't a big issue in practice).
Thanks,
VZ