-
Notifications
You must be signed in to change notification settings - Fork 27
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
Unable to build on FreeBSD #33
Comments
Thanks, we'll switch to 7.5 after CQ2.1 is released. I'll look into this later. Note that you have to use the headers included in this project (AFAIR I did one forward declaration to be able to compile). |
Thanks for the tip. I was compiling against the headers installed on the system. I've changed that now and I get the following error on the first file being compiled (which is different to before):
|
Could you try again with the latest master and also share all the logging form the first phase ( |
I've updated my port to use the latest prwrap and OCP and with the addition of a few more command line switches to pywrap, everything seems to have gone well. The generated files compile and I at last have a locally generated OCP. Awesome. The only thing that concerns me is right at the end where some QA tests are done by the ports infrastructure and it complains that various opencascade libraries are lacking an SONAME. I would need to contact the port maintainer for cad/opencascade to see if anything could be done about this. I've attached a log of the complete build for interest: |
I also get the following error when trying to run the latest cadquery (master) using the generated OCP.so:
|
Good to hear that there is progress. You have now two distinct issues:
|
Hey @nealie, Arch Linux also ships opencascade 7.5.0 so I've had to make some mods to get my cadquery package working there with a few caveats:
Hope that helps! |
@greyltc thanks but those are not related to the issues above. Note that CQ does not support 7.5 yet - it will come after 2.1 release. |
Has something changed with the code since I last got it working, as I cannot get it to link to libgl. Before it just magically happened, but I've tried adding it in to cmake using find_package and target_link_libraries, but to no avail. Admittedly I have zero cmake experience so I've been just googling around for ideas. |
Nothing changed in the OCP code regarding OpenGL. Maybe your distro links OCCT with OpenGL using the I think that this should do the trick (modify
Once you confirm that this works for you, I can add this change to the repo. |
I've updated to the latest code from github as the template directory wasn't present on the version I was using. This has necessitated adding VTK as a dependency. The code calls for vtk9, but the FreeBSD opencascade port uses vtk8, so lets hope there isn't a clash. So, I have a weird problem now:
CMake Error at CMakeLists.txt:23 (target_link_libraries): I can see the project specified as OCP in the CMakeLists.txtx file, so I have no idea why it thinks that it's not building OCP. |
Oops, my mistake. I didn't understand cmake enough to put the lines you told me about into the right place. I think I've corrected that now and I get this:
-- Configuring done |
The magic incantation seems to be: Everything now builds successfully, but alas all is not yet well:
|
Good, progress. Can you list all undefined symbols in OCP (using |
Here's what ld says:
|
These look interesting:
Only |
I added |
Are you sure it was indeed excluded from the generated code? If so, I'll check locally if this function is not appearring in some inline. |
Here's the patch I applied to ocp.toml, in case I specified the exclusion incorrectly. |
I just updated my build to use the latest head of OCP (1abdb76) and now I get a different undefined symbol:
|
The code in the head is for 7.5.1 , are you linking against it? I assume so. If all fails, you can generate your own Here is the script (you'll likely need to modify it to work on BSD): https://github.com/CadQuery/OCP/blob/master/dump_symbols.py |
Just to keep you up to date: I am still working on this, but with no further success. I have generated my own symbols_mangled_freebsd.dat as you suggested, but with no difference (it meant creating yet another port for lief). I have worked using the headers within the OCP repository as well as the locally installed headers. Both compile and link, yet both exhibit the same undefined symbol at execution time as before. Unfortunately you seem to have skipped from OpenCascade 7.4 to 7.5.1, whereas the FreeBSD port is currently at 7.5. Maybe this is a problem. I am now trying to enlist help from within the FreeBSD project itself, as this is obviously beyond my skills. If there is no progress there, the only way forward that I can see is to go back to the old method of using your pre-generated Linux files, which would require them to be attached to a release as before. I was trying to avoid that as it means more work for you and probably constant reminders from me for each release, which seemed unnecessary since others seems to have got this process to work. |
Using c++filt I'm able to see that the undefined symbol "_ZN19OpenGl_VertexBuffer16unbindFixedColorERKN11opencascade6handleI14OpenGl_ContextEE" is in fact: Opencascade (my version at least) defines it as: I don't know if that difference is an issue. This is conditional upon: #if !defined(GL_ES_VERSION_2_0) My OCP library is linked against the following:
So, the question is: why is this symbol missing? Am I missing a library, or is there a mismatch between opencascade and OCP? |
Now it starts to make sense, check #46 for possible solution. TLDR: use the following cmake flag when compiling OCCT:
|
Well, I found the option to turn off USE_GLES2 in the FreeBSD opencascade port, and now that symbol doesn't seem to be a problem. So, the next problem is as follows:
which translates to: Looking at the ldd output from two comments ago I can see that OCP is actually being liked against both vtk 8.2 and vtk 9.0.1. Unfortunately everything else on my system seems to be linked to vtk 8.2, so maybe this is the problem. Will OCP work with vtk 8.2? |
My suggestion would be to link everything against vtk9 (it is BTW interesting how you link against two version of VTK at once). You'll need to patch OCCT (only build related files, not code itself https://github.com/conda-forge/occt-feedstock/blob/master/recipe/vtk.patch) . I never tried with vtk8.2 , but I assume it will also work. You'll need to change the version here: Line 20 in e1df346
|
I haven't given up on getting this working, but I did get sidetracked by the FreeBSD ports system migration from Subversion to git. I now have a less convenient workflow that I can use, so I can get back to getting this working. I tried to link OCP against VTK 8.2, but I believe that the port is built without python wrapping, so there's no vtkWrappingPythonCore available. I think this means that the only way forward is to get opencascade working with VTK 9. I have talked to the FreeBSD ports maintainer for opencascade and he is unable to build against VTK 9, so I was wondering how it's done for OCP? The current version is 7.5.0 and I notice that you are, or at least were, using 7.5.1. |
The lates version of OCCT is 7.5.2 actually. I think you should be able to build VTK8 with python. Regarding linking against VTK9 you'll need a patch (only on build files AFAIR) - you can find it in the conda-forge recipe used for building OCCT. |
I can at last build a functioning OCP. The last problem was VTK and after talking to the FreeBSD cad/opencascade port maintainer, he upgraded to using VTK 9, which was not altogether straightforward as it does not work out of the box. Efforts have been undertaken to ensure that FreeCAD is not broken by this change, which apparently also needed some work, but I am hopeful that those changes will be committed which will allow me to commit my changes and we will finally have a working CadQuery on FreeBSD again. I've had to write six new ports because of new dependencies since my last port, which alas have not been already ported. This means that it will take some time to get everything committed in dependency order, but I am hopeful that it will work again.- Now all I have to do it get CQ-editor working, but that's another story. |
Good to hear! Out of curiosity what was needed regarding VTK9 and OCCT (other than the patch mentioned above)? |
I'm not totally sure, but here's the proposed patches and subsequent discussion: https://reviews.freebsd.org/D30934 |
Can you perhaps share your work up till now? I'm on FreeBSD as well, and I'd like to try to get a basic cadquery working (without cq-editor). |
Sorry for a very slow reply. I started submitting the new ports that the latest version of OCP requires quite some time ago, but they have been languishing in the bugs database until today. I have now been able to submit the next round of ports, so if you want to give it a go before it's committed, have a look at
I think that everything else has been committed now. I haven't yet tackled CQ-editor, but once this is all done, then I will. |
Thanks! Will give it a try, probably over the weekend. |
It works! There were a couple of minor issues;
I've added these as comments to the relevant bugs in the FreeBSD bugzilla. |
Honestly (and without meaning disrespect), I'm not the biggest fan of cq-editor and IDE's in general; it pulls in the whole of spyder just for syntax highlighting of the python code. :-( And the cadquery examples in the distribution are kind of useless without it. As a long-time UNIX user I favor DOTADIW. That means using my preferred editor to edit python scripts. So in my cadquery scripts I export the result to a STEP file. Then I use a separate viewer for that. Most of the existing viewers are windows-only or quite heavyweight. Although I haven't explored it properly yet, one could use DRAWEXE to e.g. automatically generate 2D views. Ideal for automated workflows. |
Discussing CQ-editor is a little bit off-topic here but note that you can use external editors with it. Also note that CQ has SVG exporting capabilities for "2D views". |
@nealie given what @rsmith-nl wrote above, can this issue be closed (i.e. it sounds like OCP can be built on FreeBSD)? Or am I missing something? |
Yes, at least I can build it and hopefully once all of the ports have been committed so will everyone else. It has been a long and tortuous process, but we're almost there. |
@nealie What's the status is this port? Is there any chance of CadQuery running on FreeBSD on an ARM 64 system? |
Unfortunately the committing of all the ports has stalled due to many, many dependencies and in the meantime I am no longer able to build OCP on FreeBSD. I have temporarily lost to will to continue banging my head against this, but hopefully I can try again once the versions of the required libraries in ports match those required by OCP. |
Since the FreeBSD opencascade port has been updated to 7.5.0 my port of OCP 7.4 using pre-generated files no longer works, so I thought it was time to revisit trying to get it all to generate using bindgen. Unfortunately this still does not work for me, so I thought this was a more suitable forum than the google groups to try and work out why it's failing.
I've attached a log of my failing build, which has quite a lot of bindgen failures, so it's no surprise that the results don't all compile. I've also attached my Makefile (called Makefile.txt because this silly web interface won't accept anything else).
Any insight into what I can do to get this working would be highly appreciated.
Makefile.txt
build.log
The text was updated successfully, but these errors were encountered: