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

debug build lpy #28

Open
fredboudon opened this issue Jun 3, 2021 · 2 comments
Open

debug build lpy #28

fredboudon opened this issue Jun 3, 2021 · 2 comments
Assignees

Comments

@fredboudon
Copy link
Owner

  • make a devbuild.bat
  • test if conda_prefix is set before setting it to a default value
  • add conda install cmake dans la doc
  • explain compilation on windows in the doc
  • add undefined-symbol flag for osx compilation
  • fix ui file
@j-levy
Copy link
Collaborator

j-levy commented Jun 4, 2021

I wrote the doc and tweaked the windows build script. Now it activates both Developer Command Tools and Conda environments by calling the scripts inside the build script. If someone wants to build manually, the doc is written for that.

By the way I tried excatly ALL versions of CMake found in conda-forge and I couldn't generate a project using NMake Generator.

  • CMake=3.12 -> 3.15 versions think that Python 3.9 is not a valid version (CMake is too old)
  • CMake=3.16 -> 3.20 versions are not happy with Boost being a 64 bits library (finds 64 bits, says it needs 32 bits)
  • Same behaviour with Cmake=3.19 from VS 2019

CMake must be fixed at >= 3.16 if you're targetting Python 3.9.

I try to install boost-cpp=1.67, which is the latest version that has been built for both Win-32 and Win-64 available on Anaconda.org, but it raises a ton of conflicts. Maybe the NMake Generator has a FindBoost module that raises errors when it only finds one version (x64) of Boost?

As far as I can tell, the simplest way to fix this issue is to switch to the Visual Studio 16 2019 generator, which is up-to-date and finds 64-bits Boost library correctly.

There's still the LDFLAG missing in some CMake files to compile on macOS without specifying the LDFLAG manually.

@j-levy
Copy link
Collaborator

j-levy commented Jun 14, 2021

Instead of using the -undefined dynamic_lookup flag I tried to be cleaner and smarter and check what flags were missing.

They were Python methods that weren't defined when linking. Great, I thought, I'd just put target_library_link(targetname ${Python3_LIBRARIES} and we'll be good.

Adding this works on Windows (compiles and runs), but on macOS, it compiles correctly but fails to run. When launching lpy it says error in python malloc with an obscure memory address. (Tested on macOS 11.4, Xcode 11.3, Python 3.9, Lpy 3.8.0). When running any python module it justs says Segfault 11.

After trying to compile it multiple times with various flags, I couldn't make it run correctly with this target_link_library, so I decided to go as planned and rely on the -undefined dynamic_lookup. This works okay. PR on the way!

pradal added a commit that referenced this issue Jan 26, 2024
Update channels for deployment on conda
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

No branches or pull requests

2 participants