#40298 closed defect (fixed)
lisaem: tries to build as 64-bit against wxWidgets-2.8
Reported by: | mojca (Mojca Miklavec) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: | lisaem |
Description
It looks like lisaem tries to be built as 32-bit despite r110329.
This is copied from the buildbot (https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/20090/steps/compile/logs/stdio):
Compiling LisaConfigFrame.cpp... Linking ./bin/LisaEm.app ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_macu_richtext-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_macu_aui-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_macu_xrc-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_macu_qa-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_macu_html-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_macu_adv-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_macu_core-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_base_carbonu_xml-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_base_carbonu_net-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) ld: warning: in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8/lib/libwx_base_carbonu-2.8.dylib, file was built for i386 which is not the architecture being linked (x86_64) Undefined symbols for architecture x86_64: "wxAppConsole::ms_appInitFn", referenced from: __static_initialization_and_destruction_0(int, int)in lisaem_wx.o "wxGetTopLevelParent(wxWindow*)", referenced from: wxTopLevelWindowBase::IsActive() in lisaem_wx.o wxTopLevelWindowBase::IsActive() in LisaConfigFrame.o "wxFrameBase::wxFrameBase()", referenced from: LisaEmFrame::LisaEmFrame(wxString const&)in lisaem_wx.o LisaConfigFrame::LisaConfigFrame(wxString const&, LisaConfig*)in LisaConfigFrame.o
Change History (7)
comment:1 Changed 11 years ago by mojca (Mojca Miklavec)
comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
comment:3 follow-up: 5 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
At least, that's part of the problem. I'm on Mountain Lion and I have wkgtk-2.8 installed +universal, and lisaem failed to build because wxgtk-2.8's -arch
flags leaked into the build. When I removed the -arch
flags from wx-config, I was able to build lisaem on Mountain Lion.
But this bug report is about Snow Leopard, which is using wxWidgets-2.8 instead, so this may be a different problem. I have not tested on Snow Leopard yet.
comment:4 Changed 11 years ago by mojca (Mojca Miklavec)
Oh, sorry. I'll commit it, but I don't dare to make a blind commit without testing based on recent experience ;).
But anyway, judged from CC='...'
in the environment this problem seems to happen before any configuration takes place at all. I don't think that the flags passed by MacPorts have anything to do with faulty wx-config
.
comment:5 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Replying to ryandesign@…:
But this bug report is about Snow Leopard, which is using wxWidgets-2.8 instead, so this may be a different problem. I have not tested on Snow Leopard yet.
I didn't realize wxWidgets.use
would change supported_archs
. That means any use of get_canonical_archflags
must occur after wxWidgets.use
is called. Fixed for lisaem in r110352 but I don't know if other ports have the same issue.
comment:6 Changed 11 years ago by mojca (Mojca Miklavec)
r110352 you mean? Thank you, that lead to a successful build on Snow Leopard on the buildbot.
comment:7 Changed 11 years ago by mojca (Mojca Miklavec)
As for the other ports: the only ports that mess with archflags are:
- py-robotframework-ride, broken (#40297)
- py-wxpython-2.8, but I think that it's done properly there because there is duplicated code
- wxWidgets itself uses
set archs [join ${configure.universal_archs} ,]
for universal (I think this is not problematic) - plplot where wxWidgets-3.0 doesn't set any architectures
- esdl which doesn't explicitly include wxWidgets (I don't know how exactly it works)
- relax does something that I don't understand (but it also depends on version 2.9 which should be ok)
Please note that it's also not excluded that it's a bug in the
wxWidgets
PortGroup.The flags being used are:
This:
should trigger the code
from the PortGroup, but maybe something is broken.