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.012167
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 .. 58 Next › Last »

<deleted-account> commented on 2012-05-30 22:46 (UTC)

Thanks for fixing the M_PI stuff. Unfortunately it would still not compile for me and break with the following error: Core/Approximation.cpp:58:31: fatal error: Eigen/LeastSquares: No such file or directory But it is a simple fix Append the following to the call of the configure script in the PKGBUILD file A backslash "\" to the last line and after that add the following line --with-eigen3-include=/usr/include/eigen3/ call makepkg in the folder with PKGBUILD, then install the generated package with pacman -U filenameofgeneratedpackage.tar.xz

gborzi commented on 2012-05-14 22:07 (UTC)

Fixed.

PerisH commented on 2012-05-14 17:55 (UTC)

Hi! I'm having problems to compile the package. This last two weeks when i tried to compile and this error can't let me build freecad-git and my actual version is broken. ././src/SMESH/SMESH_MeshEditor.cpp:6972:53: warning: narrowing conversion of 'nSide[1].std::list<_Tp, _Alloc>::size<const SMDS_MeshNode*, std::allocator<const SMDS_MeshNode*> >()' from 'std::list<const SMDS_MeshNode*>::size_type {aka long unsigned int}' to 'int' inside { } is ill-formed in C++11 [-Wnarrowing] make[4]: *** [SMESH_MeshEditor.lo] Error 1 make[4]: se sale del directorio `/tmp/yaourt-tmp-perish/aur-freecad-git/src/freecad-build/src/3rdParty/salomesmesh' make[3]: *** [all-recursive] Error 1

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.

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