Package Details: freecad-git 0.22.0.36999.ged77603af9-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.freecad.org/
Licenses: LGPL
Conflicts: freecad, freecad-appimage, freecad-appimage-git
Provides: freecad
Submitter: gborzi
Maintainer: greyltc (adrianinsaval)
Last Packager: adrianinsaval
Votes: 104
Popularity: 0.040540
First Submitted: 2012-03-03 13:46 (UTC)
Last Updated: 2024-04-30 00:29 (UTC)

Pinned Comments

adrianinsaval commented on 2023-03-12 14:50 (UTC)

If the check fails there is little I can do about it as it most likely needs to be fixed upstream, in such cases report those upstream (maybe wait a day or two as sometimes it's quickly solved upstream) or skip the check with makepkg --nocheck if you don't care about the functionality that is being reported as failing in the check.

Latest Comments

« First ‹ Previous 1 .. 41 42 43 44 45 46 47 48 49 50 51 .. 57 Next › Last »

gborzi commented on 2012-04-06 16:33 (UTC)

This new PKGBUILD fixes the problem reported by Tempel. It adds -fpermissive to the compilation flags to get rid of the error.

gborzi commented on 2012-04-05 16:28 (UTC)

@Tempel I have the same problem with -git, haven't tried freecad stable. Tried recompiling both soqt and coin, but it still fails with that error message. So, I came to the conclusion that it could be a compiler problem, it is the only relevant thing that has recently changed. Downgrading gcc to 4.6.3 solves the problem.

Tempel commented on 2012-04-05 01:14 (UTC)

Building fails for me during the configure step with: checking whether libSoQt is available... false configure: error: **** Cannot find SoQt devel files. **** I installed soqt as a dependency of pivy-hg just for this package, so I'm certain it's there. This occurs with both freecad and freecad-git packages. Any thoughts?

gborzi commented on 2012-03-14 20:09 (UTC)

I found a workaround to the boost "hard" dep problem. Now the package() function includes a few lines that create symlinks under /usr/lib/freecad-git/lib for the required versioned boost libraries to the unversioned ones, e.g. ls -l /usr/lib/freecad-git/lib/libboost_* returns lrwxrwxrwx 1 root root 31 Mar 14 20:46 /usr/lib/freecad-git/lib/libboost_filesystem.so.1.49.0 -> /usr/lib/libboost_filesystem.so lrwxrwxrwx 1 root root 36 Mar 14 20:46 /usr/lib/freecad-git/lib/libboost_program_options.so.1.49.0 -> /usr/lib/libboost_program_options.so lrwxrwxrwx 1 root root 26 Mar 14 20:46 /usr/lib/freecad-git/lib/libboost_regex.so.1.49.0 -> /usr/lib/libboost_regex.so lrwxrwxrwx 1 root root 28 Mar 14 20:46 /usr/lib/freecad-git/lib/libboost_signals.so.1.49.0 -> /usr/lib/libboost_signals.so lrwxrwxrwx 1 root root 27 Mar 14 20:46 /usr/lib/freecad-git/lib/libboost_system.so.1.49.0 -> /usr/lib/libboost_system.so and ldd /usr/bin/freecad-git |grep boost returns libboost_program_options.so.1.49.0 => /usr/lib/freecad-git/lib/libboost_program_options.so.1.49.0 (0x00007f12a031f000) libboost_signals.so.1.49.0 => /usr/lib/freecad-git/lib/libboost_signals.so.1.49.0 (0x00007f12a010b000) libboost_regex.so.1.49.0 => /usr/lib/freecad-git/lib/libboost_regex.so.1.49.0 (0x00007f129fe01000) libboost_filesystem.so.1.49.0 => /usr/lib/freecad-git/lib/libboost_filesystem.so.1.49.0 (0x00007f129fbe2000) libboost_system.so.1.49.0 => /usr/lib/freecad-git/lib/libboost_system.so.1.49.0 (0x00007f129f9df000) This applies to freecad as well, I tested it by compiling freecad with boost 1.48.0, then upgrading boost.

gborzi commented on 2012-03-14 17:24 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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

Xyne commented on 2012-03-13 18:56 (UTC)

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!

« First ‹ Previous 1 .. 41 42 43 44 45 46 47 48 49 50 51 .. 57 Next › Last »