On Friday, March 27, 2015 02:18 AM, Christophe Geuzaine wrote:
On 25 Mar 2015, at 19:33, Isaac Ayala <[email protected]> wrote:
<lukshuntim@...> writes:
On Sunday, March 22, 2015 03:47 PM, Christophe Geuzaine wrote:
On 21 Mar 2015, at 20:04, Isaac Ayala <isaac.ayalaiii@...> wrote:
[snipped]
Hi Issac,
In teh mean time, if you really need it, see if you'd like to try stow
as a workaround.
https://www.gnu.org/software/stow/
Quite simple to use, IMHO. Configure the build to install gmsh under its
own directory, e.g., /usr/local/stow/gmsh and run stow to create
symbolic links to the usual local installation hierarchy /usr/local.
Uninstallation is then simply "un"-stowing and deleting the
/usr/local/stow/gmsh tree.
Regards,
ST
Please pardon the late reply, I'll test stow later. I'll have to get a good
understanding of how simlinks work tough.
As to the local installations, where exactly is gmsh searching for the .so
files then?
Hi Issac,
"ldd gmsh" will show you what shared libraries gmsh is linked to.
I can confirm the existence of the libTKSTEP files in the /usr/local/lib
folder, i'll see if I can get CMake to link to that folder in the meantime.
CMake found it, since it built Gmsh. Just add /usr/local/lib to your
LD_LIBRARY_PATH and you should be be good to go.
Presumably you have (sudo) root permission since you can install stuff
under the /usr/local hierarchy, the standard practice (in debian-like
systems) is to create an entry under /etc/ld.so.conf.d/ and run
"ldconfig" to update the system default shared library search paths.
Anyway, this is getting OT and you can find a lot on information out
there.
Regards,
ST
--
_______________________________________________
gmsh mailing list
[email protected]
http://www.geuz.org/mailman/listinfo/gmsh
