Package Details: freecad-git 0.19.r582.g0cfea3fee3-1

Git Clone URL: https://aur.archlinux.org/freecad-git.git (read-only, click to copy)
Package Base: freecad-git
Description: A general purpose 3D CAD modeler - git checkout
Upstream URL: https://www.freecadweb.org/
Licenses: LGPL
Conflicts: freecad, freecad-appimage, freecad-appimage-git
Provides: freecad
Submitter: gborzi
Maintainer: greyltc
Last Packager: greyltc
Votes: 96
Popularity: 0.54
First Submitted: 2012-03-03 13:46
Last Updated: 2021-05-09 15:39

Required by (3)

Sources (1)

Latest Comments

« First ‹ Previous ... 29 30 31 32 33 34 35 36 37 38 39 ... Next › Last »

gborzi commented on 2011-12-01 17:36

@eworm
I think it would work, but when boost changes version I'll upload a new PKGBUILD anyway.

eworm commented on 2011-12-01 16:16

@gborzi
That's true... Something I suffer from time to time, especially with boost. ;)

Does something like this work?

_boostver=`pacman -Q boost-libs | cut -d\ -f2 | cut -d- -f1`
depends(boost-libs=${_boostver} ...)

This would give hard dependency in the binary package, but make it compile with whatever boost version is installed.

gborzi commented on 2011-12-01 16:01

@cgx
I'll try compiling with 1.48 this evening.
@eworm
Without the hard dep an upgrade to boost would break the package, a break that woudn't be noticed until one tries to launch the binary.

eworm commented on 2011-12-01 15:35

Uh, why does this have a hard dependency on boost?
Usually recompiling the package fixes the problem.

cgx commented on 2011-12-01 15:30

Any chance of compatability with boost-libs 1.48? It's in testing now

eworm commented on 2011-09-28 19:04

No problem. ;)
I do have my own build scripts that patch the PKGBUILD before the package is compiled. So I'm fine with it now. Thanks!

gborzi commented on 2011-09-28 16:38

@eworm
Up to now you are the only one with this problem, unless others report the same, I won't change the package. It is more probable that there is something in your setup that causes this problem, rather than an issue in the package.

eworm commented on 2011-09-27 20:38

Ok, got it...

Installed both, freecad and freecad-svn, with:

./configure \
--prefix=/opt/${pkgname} \
--includedir=/usr/include/${pkgname} \
--docdir=/usr/share/doc/${pkgname} \
[...]

That is the only way I could get run both side by side.

Note that you have some more things to change, e.g. link from /usr/bin/$appname to /opt/${pkgname}/bin/$appname, etc.

eworm commented on 2011-09-26 06:45

I will try rebuilding as soon as I have access to more powerful hardware.

Just took a look at the pathes... I would expect prefix to be set to /usr, then libdir to /usr/lib/freecad-svn, datarootdir to /usr/share/freecad-svn, etc. That would install the binaries to /usr/bin as expected. However this way it is not possible to change the path for the modules... They would be installed to /usr/Mod (with then conflicts with package freecad). I would expect them to be installed in /usr/lib/freecad-svn/Mod or /usr/share/freecad-svn/Mod. Is there any chance to change that?

BTW, even starting freecad-svn with -M /usr/lib/freecad-svn/Mod/ does not change anything... Still loading from /usr/lib/freecad/Mod/.

gborzi commented on 2011-09-23 21:12

The same command gives
open("/usr/lib/freecad-svn/Mod/Raytracing/tls/x86_64/libRaytracingGui.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/freecad-svn/Mod/Raytracing/tls/libRaytracingGui.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/freecad-svn/Mod/Raytracing/x86_64/libRaytracingGui.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/freecad-svn/Mod/Raytracing/libRaytracingGui.so.2", O_RDONLY) = 28
on my system. As I implied in the previous comment, I recompiled freecad-svn with freecad installed because I suspected it was linking against the freecad libraries. What happens if you uninstall freecad?