Package Details: solvespace-git r2194.3e5873e6-1

Git Clone URL: https://aur.archlinux.org/solvespace-git.git (read-only, click to copy)
Package Base: solvespace-git
Description: Parametric 2D/3D CAD
Upstream URL: https://solvespace.com
Keywords: cad design
Licenses: GPL3
Conflicts: solvespace
Provides: solvespace
Submitter: keenerd
Maintainer: awahab
Last Packager: awahab
Votes: 11
Popularity: 0.78
First Submitted: 2015-08-09 17:08 (UTC)
Last Updated: 2026-04-01 00:46 (UTC)

Dependencies (5)

Required by (0)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

gerhard commented on 2017-01-09 01:04 (UTC)

makepkg stopped with "a required package was not found" After changing the dependency "gtkmm" to "gtkmm3" in PKGBUILD the package compiled and installed just fine. But when I tried to run solvespace a window came up for a very short time and then the programm immediately crashed with memory access error. Maybe it helps to say that this was the first time that I tried to install solvespace. In order to learn this 3DCAD system I later installed the other "solvespace" package from AUR (which is from older version 2.2) and could compile and install a working program.

shutdown-hnow commented on 2016-10-12 11:14 (UTC)

Hmm, that is strange. ldd /usr/bin/solvespace|grep -i glew libGLEW.so.1.13 => /usr/lib/libGLEW.so.1.13 (0x00007f1a2fc1a000)

keenerd commented on 2016-10-12 11:08 (UTC)

No, I have no such symlink. It really does work fine with Glew 2.0.0. (And symlinking libraries like that is extremely bad.) I don't want to say "It is your fault" but it seems like something is fishy with your install. Incidentally 'ldd' finds no direct link between Solvespace and Glew so it is probably not a problem with Solvespace.

shutdown-hnow commented on 2016-10-12 10:53 (UTC) (edited on 2016-10-12 10:56 (UTC) by shutdown-hnow)

Thanks, the sed line is much cleaner. The error I get is this: "solvespace: error while loading shared libraries: libGLEW.so.1.13: cannot open shared object file: No such file or directory" Maybe you have a symlink in place?

keenerd commented on 2016-10-09 14:34 (UTC)

It builds for me with the test. I've added a oneliner in prepare() you can uncomment though. And it runs fine with glew 2.0.0 here. Can you be more specific about that error?

shutdown-hnow commented on 2016-10-09 13:40 (UTC)

I could only get it to compile after disabling the ttf_text tests, as they failed (maybe because of differing font rendering settings). If you have the same problem you can use the following patch: diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt index 40b7436..09909d8 100644 --- a/test/CMakeLists.txt +++ b/test/CMakeLists.txt @@ -52,7 +52,7 @@ set(testsuite_SOURCES request/cubic_periodic/test.cpp request/datum_point/test.cpp request/line_segment/test.cpp - request/ttf_text/test.cpp) + ) add_executable(solvespace_testsuite ${testsuite_SOURCES}) Save it as disable-ttf_text-tests.patch in the directory where the PKGBUILD resides and change the following lines in the PKGBUILD: source=('solvespace-git::git+https://github.com/solvespace/solvespace.git' 'disable-ttf_text-tests.patch') sha256sums=('SKIP' 'SKIP') Now add the following line to the prepare() function: git apply "${srcdir}"/disable-ttf_text-tests.patch And it should compile. I also had to install glew1.13 from the AUR before it would run, so this should be added as a dependency instead of glew, which is now at 2.0.0 in the main repository.

tesfabpel commented on 2016-06-07 06:35 (UTC) (edited on 2016-06-07 06:56 (UTC) by tesfabpel)

After some testing, this is my PKGBUILD... it seems to work :) Please test again anyway... https://gist.github.com/tesfabpel/a8a4a1e3a41f53788b0fe493a2ad827f BTW, why doesn't it point to the solvespace/solvespace repo? Thanks.

tesfabpel commented on 2016-06-06 19:54 (UTC)

I tried adding this: prepare() { cd "$pkgname" git submodule update --init extlib/libdxfrw } And it compiles, but then pacman gives this error: /usr/lib64 is already in the filesystem

tgirod commented on 2016-05-18 09:56 (UTC)

to compile, it is necessary to update the submodules, but I'm not sure where this should go. git submodule update --init extlib/libdxfrw

« First ‹ Previous 1 2 3 Next › Last »