Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Macos fixes #396

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

[WIP] Macos fixes #396

wants to merge 2 commits into from

Conversation

sbusch42
Copy link
Member

This pull request contains a number of fixes or rather workarounds that were needed on my macos system to somehow repair rendering with gloperate. It seems that the type infos are somehow mixed up, and unfortunately it seems rather unpredictable what works in what situation.

A summary on what errors I encountered:

RenderPassStage(126):
typeid check for Input<globjects::Texture *> fails, dynamic_cast works. Therefore I replaced all typeid checks with dynamic casts, which for some reason created errors in other parts (see below).

Stage.inl(41):
dynamic_cast for Inputcppassist::FilePath fails, typeid() works. For all other types, the dynamic cast seems to work. It seems that the typeinfo for this class is not exported properly, and it is the only case where we have a class from cppassist, the property specialization in cppexpose, and it is used in gloperate.

RenderInterface.cpp(59): (unsolved)
For some reason, dynamic_cast for Output<DepthRenderTarget *> fails. However, dynamic_cast for Output<ColorRenderTarget *> works fine. I have no idea how to fix this.

I tried a number of things to fix the typeinfo problems in general, none of which made any difference:

  • Use typeid.hash_code() for comparison
  • Use CXX_VISIBILITY_PRESET="default" instead of "hidden"
  • Use -fvisibility-ms-compat
  • Load dynamic libraries with RTLD_GLOBAL and/or RTLD_NOW

I hope someone has an idea how to fix this properly, I'm currently out of ideas.

Stefan Buschmann and others added 2 commits August 20, 2017 09:35
… between dynamic library boundaries seem to fail on macos
…ts and typeid (NOT a real solution, but makes it at least render something)
@sbusch42
Copy link
Member Author

@j-o
Copy link
Contributor

j-o commented Aug 21, 2017

CXX_VISIBILITY_PRESET="default" works for me (on master, not this PR). Did you set this for all middleware projects?

@sbusch42
Copy link
Member Author

only for cppexpose and gloperate, because I was lazy. I can try again setting it for all of them ...

@sbusch42
Copy link
Member Author

Okay, so I compiled everything with visibility=default. The viewer does not crash anymore, so the strange problem with dynamic_cast<Output<DepthRenderTarget *>> seems to be gone. The problem in Stage.inl still exists, I have to replace typeid with dynamic_cast to get it to work.

So, what shall we do here? Use default visiblity and work around the typeid problem, hoping that it works the same on all computers? Or try to find the problems with our exports (see the blog post I linked above)? Or try to rewrite our type system so that we do not have to rely so heavily on the C++ RTTI any more, e.g., by using self defined type names? We should find a way to solve this properly, soon.

@j-o
Copy link
Contributor

j-o commented Aug 23, 2017

I thought it was the other way around for cppassist::FilePath?

dynamic_cast for Inputcppassist::FilePath fails, typeid() works

Anyway, both work on my system (using "Apple LLVM version 8.1.0 (clang-802.0.42)" btw).

@sbusch42
Copy link
Member Author

Yes, as I mentioned in my first post, sometime typeid fails, sometimes dynamic_cast, it's pretty much unpredictable. This time, FilePath was not the problem, but Texture.

Unless I have done something very stupid in my setup (which I doubt), we have a serious problem with dynamic libs and our type system on macos, which we must think about and solve. "Works for me" is unfortunately not a solution.

@j-o
Copy link
Contributor

j-o commented Aug 23, 2017

Do you have some test code for this? I could not find a call to input<globjects::Texture *> within gloperate.

@j-o
Copy link
Contributor

j-o commented Aug 23, 2017

I'm sorry for asking what is probably a stupid question, but if you are testing with an external project using gloperate, did you set visibility=default for that, too? Since you are talking about an inl-file, the code would get compiled into the using project and not gloperate.

@sbusch42
Copy link
Member Author

sbusch42 commented Aug 23, 2017

That's not a stupid question at all :) But I'm not testing with an external project, all I said happens with gloperate-viewer and the standard demos (ShapeDemo).

@j-o
Copy link
Contributor

j-o commented Aug 23, 2017

Hm... one more (stupid?) project-setup thing that tripped me up a couple of times: making some changes to the demo-stages-plugin (such as the symbol visibility ;)) and then hitting "build" in you IDE with the current target set to "gloperate-viewer" won't recompile the plugin, as there is no build-time dependency between them.

If that's not the problem, then I give up on pushing the visibility=default solution (for now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants