[Gmsh] GMSH problems in Arch Linux-64 bit

lukshuntim at gmail.com lukshuntim at gmail.com
Fri Mar 27 15:22:07 CET 2015


On Friday, March 27, 2015 02:18 AM, Christophe Geuzaine wrote:
>
>> On 25 Mar 2015, at 19:33, Isaac Ayala <isaac.ayalaiii at gmail.com> wrote:
>>
>> <lukshuntim at ...> writes:
>>
>>>
>>> On Sunday, March 22, 2015 03:47 PM, Christophe Geuzaine wrote:
>>>>
>>>>> On 21 Mar 2015, at 20:04, Isaac Ayala <isaac.ayalaiii at ...> 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
--