delorie.com/archives/browse.cgi | search |
X-Authentication-Warning: | delorie.com: mail set sender to geda-help-bounces using -f |
X-Recipient: | geda-help AT delorie DOT com |
Message-ID: | <20210623181906.23161.qmail@stuge.se> |
Date: | Wed, 23 Jun 2021 18:19:06 +0000 |
From: | "Peter Stuge (peter AT stuge DOT se) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com> |
To: | geda-help AT delorie DOT com |
Subject: | Re: [geda-help] Re: Gschem segfaults |
MIME-Version: | 1.0 |
In-Reply-To: | <20210623175103.c7c336e0b897ebc57cb7f1d2@gmail.com> |
<alpine DOT DEB DOT 2 DOT 21 DOT 2106231320280 DOT 1245 AT nimbus> | |
Reply-To: | geda-help AT delorie DOT com |
Errors-To: | nobody AT delorie DOT com |
X-Mailing-List: | geda-help AT delorie DOT com |
X-Unsubscribes-To: | listserv AT delorie DOT com |
Roland Lutz wrote: > Do you have a file `PREFIX/lib/libgedacairo.so.1'? This is probably a > symlink to `libgedacairo.so.1.0.3'; does that file exist, as well? Good question. > You can find out the path where gschem expects to find > `libgedacairo.so.1' by running: > > ldd PREFIX/bin/gschem | grep gedacairo This only shows the paths for shared libraries *found* by ld.so. If binaries were linked with -rpath to include further directories to be searched for shared objects then that can be inspected using readelf, but in this case no more research should be needed. John L. Males (jlmales AT gmail DOT com) [via geda-help AT delorie DOT com] wrote: > I did a "./configure", "make", and "sudo make install" for the > directory "geda-gaf-1.10.2" created after the tar-xf of the source > tarball. Okay. > I have found files in /usr/local/lib that match the time of the > "sudo make install" (hand typing from system that compiled on): > > libgedacairo.la > libgedacairo.so -> libgedacairo.so.1.0.3 > libgedacairo.so.1.0.1 -> libgedacairo.so.1.0.3 > libgedacairo.so.1.0.3 > libgeda.la > libgeda.so -> libgeda.so.47.0.0 > libgeda.so.47 -> libgeda.so.47.0.0 > libgeda.so.47.0.0 > > > gschem is in /usr/local/bin Great. Running: export LD_LIBRARY_PATH=/usr/local/lib in the shell before you start gschem should allow gschem to start. You could also try ( echo /usr/local/lib >> /etc/ld.so.conf && ldconfig ) for the same result but system-wide, although that will go away once you reboot the live system. Kind regards //Peter
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |