Mac OS X 10.10+ version

[tluyben]

I did some work on it, but cannot get the build to finish on Yosemite. After fixing all the other errors, the errors still popping up are related to wxwidgets and there my knowledge of linking internals ends ; I would not know how to fix those. Here they are;

https://gist.github.com/tluyben/b7777f0f766bddf93d2a

wxwidgets is the latest (3.0.2 which is included does not actually compile on Yosemite) from git; it compiles fine, for x86_64, but linking (with GD, nothing to do with wxwidgets it seems) just gives these errors.

I think after this hurdle it'll run though; any idea what causes this?

[victorlevasseur]

Seems like wxTreeCtrl is not implemented in wxWidgets. You should try to compiler wxWidgets 3.0.2 instead of the git version, but not the provided one, the version available on the website (there should be a version for Mac OSX) : https://www.wxwidgets.org/downloads/

[tluyben]

I tried both already; I resorted to compiling the git version because the homebrew & binary version gave the same error and the 3.0.2 version doesn't compile on Yosemite. Only the git version does.

Edit: I'll try to include wxTreeCtrl explicitly.

[4ian]

It seems that wxGenericHyperlinkCtrl is also missing (vtable for wxGenericHyperlinkCtrl [...]).
It is really strange: wxGenericHyperlinkCtrl and wxTreeListCtrl (not wxTreeCtrl @victorlevasseur 😉) are not bundled in the version provided by homebrew and binary version? Sounds odd :/

[tluyben]

It sounds really odd; feels like I must be doing something wrong, but I tried pointing directly (using the ld command line which generates this error) to all different libs and they result in that same error. I'm rebuilding now, see if that makes a difference.

[tluyben]

This

nm -g /usr/local/Cellar/wxmac/3.1.0/lib/*.dylib |grep TreeList

results in a quite a bit of exported TreeList stuff, including;

__ZN14wxTreeListCtrl10DeleteItemE14wxTreeListItem

so I think it's there all along; why would it not pick that up? Same for;

__ZTI22wxGenericHyperlinkCtrl

Ok, it needs;

-lwx_osx_cocoau_adv-3.1

which is not there in the link.txt, then it doesn't have this issue, but the next;

ld: internal error: atom not found in symbolIndex(__ZN22wxScopedCharTypeBufferIcE14CreateNonOwnedEPKcm)

[4ian]

Modify each CMakeLists.txt to add adv to each line beginning with:

find_package(wxWidgets COMPONENTS core

For example, this line:

find_package(wxWidgets COMPONENTS core base ribbon stc aui propgrid richtext html xrc REQUIRED)

would become:

find_package(wxWidgets COMPONENTS core base adv ribbon stc aui propgrid richtext html xrc REQUIRED)

This enables the use of the wxWidgets adv library (that contains wxTreeListCtrl and wxGenericHyperLinkCtrl). When it's done, restart the build process from the beginning: erase your build folder and launch CMake again 😄

[tluyben]

I did that, the error now is ;

ld: internal error: atom not found in symbolIndex(__ZN22wxScopedCharTypeBufferIcE14CreateNonOwnedEPKcm)

[4ian]

Ok, so it's a bit better because no need to tweak link.txt by hand (I'll add adv to all CMakeLists.txt).

For your error, I'm afraid I don't really know what cause it.. But googling it returns result related to incompatibilites between compilers.
What compiler are you using? Is it the same as the wxWidgets version you're using?

[tluyben]

Yes it is indeed the same version. I compiled wx from scratch and then GD.

On Mon, Dec 29, 2014, 17:17 Florian Rival notifications@github.com wrote:

Ok, so it's a bit better because no need to tweak link.txt by hand (I'll
add adv to all CMakeLists.txt).

For your error, I'm afraid I don't really know what cause it.. But
googling it returns result related to incompatibilites between compilers.
What compiler are you using? Is it the same as the wxWidgets version
you're using?

—
Reply to this email directly or view it on GitHub
#64 (comment).

[4ian]

Strange, strange :/ Are you sure GD is not being compiled/linked against a version of wxWidgets provided by another source (and so potentially not compiled with the same compiler?)

[tluyben]

Well as far as I understand, if I have (as only reference to wxwidgets libs);

-L/usr/local/Cellar/wxmac/3.1.0/lib

in the /bin/ld commandline, then ;

-lwx_osx_cocoau_propgrid-3.1

etc will retrieve from that directory and the libs in that directory are 100% surely made by the same compiler which is the compiler + tools from ;

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/

[tluyben]

If someone is interested to figure this out I can give access to a mac os x install via teamviewer for any amount of time needed. It has all requirements installed and root access.

[victorlevasseur]

When you have built wxWidgets, have you followed the step in WXWIDGETS_SOURCE_FOLDER/docs/osx/install.txt ?

[4ian]

@tluyben I would be interested in trying to compile GD on Mac OS X using teamviewer. 😃 But I think it could take a lot of time and I don't want to bother you! Will you be able to use another computer while I'm trying to compile using teamviewer?

[tluyben]

Sorry for the belated response, but that's fine; I just spun up a new VM, you can use it. Can you mail me so we can exchange credentials? You can tinker as long as you want, but as you wrote this project, I don't think it will take you a long time :) It's probably my quite novice wxWidgets/C++ knowledge holding me back here.

[4ian]

Not sure where I can get your email address? Mine is Florian.rival [at] gmail.com :)

[4ian]

I'm doing tests for compiling GD on Mac: the atomrelated error is due to the flag -s being used, it should be removed when not compiling with gcc.

[4ian]

Should be fixed now :) I still have to write doc on how to build on MacOS but with homebrew and by following the traditional cmake workflow, should be quite easy :)