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 ... 27 28 29 30 31 32 33 34 35 36 37 ... Next › Last »

gborzi commented on 2012-03-14 17:24

Hi Xyne,
unfortunately, AFAIK there is no way to have freecad (or any other package linking with boost) linking against the unversioned symlinks. That is so because the soname of boost libraries includes the complete version number, e.g.
objdump -p /usr/lib/libboost_system.so |grep SONAME
returns
SONAME libboost_system.so.1.49.0
Actually, it would make more sense to have the unversioned symlinks in boost rather than boost-libs. It's an upstream problem, but they don't seem interested in fixing it, i.e. in having a sane (so)name versioning policy. Besides, there is no guarantee that the next 1.50.0 boost version will be compatible with the current one.
The main problem with method 1) is that an upgrade to boost breaks the package leaving the user unaware that the package is no longer working, until (s)he tries to launch it. Which can lead to embarassing situation, e.g.
Linux user: I can open this .step file with freecad... Oops, it isn't working, I have to recompile it, it takes just 2 hours.
Windows/Mac user: ... (these Linux guys are really strange).

Xyne commented on 2012-03-13 22:52

I wasn't aware of the issue.

Is there no way to prevent freecad from linking to specific version of boost-libs? I thought that would have been possible because the boost-libs package provides unversioned symlinks to the current version of each library. The fact that freecad can be recompiled without further changes against the newer boost-libs indicates that the library still provides the same API. Maybe the issue could be raised upstream.

As for the currently proposed methods, in both cases freecad will break with some updates. In the second case, the user may not know why but it is easy to rebuild the package, especially with an AUR helper. In the first case, the user knows why, but he has to wait for a new PKGBUILD (or edit it himself), and also has to manually uninstall freecad before upgrading.

The first method thus requires less intervention and depends less on timely updates of the freecad AUR packages. I think that may be better, especially for the git package which the user can be expected to rebuild often, but others may disagree. I am not aware of a specific guideline in this case, so it's up to you. If you and Mickele think method 2 is better, stick with that until one of the ideal solutions can be implemented.

gborzi commented on 2012-03-13 22:00

@Xyne
thanks for merging freecad-svn with this one. Re. the dependency on boost-libs=1.49.0 we discussed it with Mickele some time ago and there are two alternatives:
1) the "soft" dep (e.g. boost-libs>=1.49.0). The problem with this is that when boost will be upgraded to, say 1.50.0, the freecad binary won't work anymore because it is linked to the previous version of that library. But you may realize it only when you try to use freecad.
2) the "hard" dep (e.g. boost-libs=1.49.0). Whenever boost gets an upgrade you'll be reminded of the need to recompile this package. The downside is that an update (i.e. pacman -Syu) wouldn't work unless you uninstall freecad.
Between the two, we opted for the second. I think the real solution to this problem would be to have an appropriate soname for the boost libraries. If you have a better solution or think that 1) is closer to the packaging guidelines than 2) please let me know.

Xyne commented on 2012-03-13 19:00

I've merged the old freecad-svn page into this one.

Xyne commented on 2012-03-13 18:59

Development has moved to Git. See https://aur.archlinux.org/packages.php?ID=57247
Deleting...

Xyne commented on 2012-03-13 18:56

Hi,

Please see my comments about specifying boost and boost-libs dependencies on the freecad package page:
https://aur.archlinux.org/packages.php?ID=7575

Thanks!

gborzi commented on 2012-03-12 21:22

@ChrisP
In case it still isn't working, check config.log (under src/freecad-build) to see if configure doesn't find something. Also, search for MovieTool.py under pkg.

Anonymous comment on 2012-03-12 06:55

@gborzi
Tried installation twice, same gremlin surfaced both times. Will clean off completely, and try once more.
Thanks for testing it at your end. ( Incidentally, the svn version of the freecad package compiled and
installed without a hitch ).

gborzi commented on 2012-03-11 16:03

@ChrisP
I recompiled the package but didn't get any error from the sed line. Please retry the build.

Anonymous comment on 2012-03-11 08:31

PKGBUILD throws an error at 'sed -i' line about missing $pkgdir/usr/lib/freecad-git/Mod/Robot/MovieTool.py