[help] ifeffit -i = segmentation fault
Hi to all,
I'm having big troubles with iFEFFIT. I have updated the systems (Linux GNU
Debian/ Testing) and I realized that version 800.025 of perl-tk was
automatically installed. After that, obviously, everything crashed with
Artemis and friends.
So I have downgraded perl-tk to 800.024 using a non standard debian package
(because the standard one requires perl-base 5.6.1 and I'm working with
perl-base 5.8.3) from here:
http://snapshot.debian.net/cgi-bin/packages.cgi
(I have used perl-tk_800.024-1.2_i386.deb)
After that I decided to recompile everything... bad idea! ifeffit-1.2.5
recompiled fine (no errors appeared in the configure/make/make install
process).
*BUT* when I try to recompile horae-034 it crash on determining ifeffit
version. In fact, if I run "ifeffit -i" it gives me:
Segmentation fault
(Killed, on another machine)
I hope someone could help me because at the moment I can do nothing! :(
Thanks,
Mauro
--
Mauro Rovezzi
Mauro, It is not clear to me why you needed to recompile everything else just because you downgraded perl/Tk. (If the problem is failed dependencies in the .deb files, perhaps Carlo could be persuaded to set the dependencies such that 800.024 is acceptable -- which it is).
After that I decided to recompile everything... bad idea! ifeffit-1.2.5 recompiled fine (no errors appeared in the configure/make/make install process).
*BUT* when I try to recompile horae-034 it crash on determining ifeffit version. In fact, if I run "ifeffit -i" it gives me:
Segmentation fault (Killed, on another machine)
Problems like this usually all lall in the same category -- version conflict. Use commands like "which", "whereis" and "locate" to try to figure out if you have multiple versions either of the ifeffit executable or the ifeffit library. My guess is that the new executable is trying to dynamically link to an old library, or vice versa. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
On Mon, May 24, 2004 at 01:46:29PM -0400, Bruce Ravel wrote:
Mauro,
It is not clear to me why you needed to recompile everything else just because you downgraded perl/Tk. (If the problem is failed dependencies in the .deb files, perhaps Carlo could be persuaded to set the dependencies such that 800.024 is acceptable -- which it is).
Because I got many errors from Athena and Artemis, so I decided to "clean". This was a bad idea... I know.
Problems like this usually all lall in the same category -- version conflict. Use commands like "which", "whereis" and "locate" to try to figure out if you have multiple versions either of the ifeffit executable or the ifeffit library. My guess is that the new executable is trying to dynamically link to an old library, or vice versa.
They only tell me that ifeffit is installed in /usr/local
--
Mauro Rovezzi
Perhaps it is a good thing to ask here, if the library naming has changed on linux as well. Certainly on the Mac it has. There the dynamic library for pgplot was changed and I saw dynamic linking errors when I tried running the latest version of horae on my home brew setup. In my solution, the solution was just to downgrade to the same perl that Matt used to build the installer and now the update_horae script works wonderfully against the binary installer version of ifeffit, horae, and friends. On May 24, 2004, at 8:08 PM, mauro@rulp.org wrote:
On Mon, May 24, 2004 at 01:46:29PM -0400, Bruce Ravel wrote:
Mauro,
It is not clear to me why you needed to recompile everything else just because you downgraded perl/Tk. (If the problem is failed dependencies in the .deb files, perhaps Carlo could be persuaded to set the dependencies such that 800.024 is acceptable -- which it is).
Because I got many errors from Athena and Artemis, so I decided to "clean". This was a bad idea... I know.
Problems like this usually all lall in the same category -- version conflict. Use commands like "which", "whereis" and "locate" to try to figure out if you have multiple versions either of the ifeffit executable or the ifeffit library. My guess is that the new executable is trying to dynamically link to an old library, or vice versa.
They only tell me that ifeffit is installed in /usr/local
-- Mauro Rovezzi
- Physics student University of Rome "Tor Vergata", ESRF Beamline BM8 - GILDA _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Dr. Paul Fons Senior Researcher National Institute for Advanced Industrial Science & Technology METI Center for Applied Near-Field Optics Research (CANFOR) AIST Central 4, Higashi 1-1-1 Tsukuba, Ibaraki JAPAN 305-8568 tel. +81-298-61-5636 fax. +81-298-61-2939 email: paul-fons@aist.go.jp The lines below are in a Japanese font 〒305−8568 茨城県つくば市東1−1−1 つくば中央第4 近接場光応用工学センター ポール・フォンス主任研究官
You are using a tarball installation obviously. I have now gotten my hands on a testing machine and I will rebuild the packages for testing too. Hopefully this will be done by this evening. Carlo On Mon, 24 May 2004, mauro@rulp.org wrote:
On Mon, May 24, 2004 at 01:46:29PM -0400, Bruce Ravel wrote:
Mauro,
It is not clear to me why you needed to recompile everything else just because you downgraded perl/Tk. (If the problem is failed dependencies in the .deb files, perhaps Carlo could be persuaded to set the dependencies such that 800.024 is acceptable -- which it is).
Because I got many errors from Athena and Artemis, so I decided to "clean". This was a bad idea... I know.
Problems like this usually all lall in the same category -- version conflict. Use commands like "which", "whereis" and "locate" to try to figure out if you have multiple versions either of the ifeffit executable or the ifeffit library. My guess is that the new executable is trying to dynamically link to an old library, or vice versa.
They only tell me that ifeffit is installed in /usr/local
-- Mauro Rovezzi
- Physics student University of Rome "Tor Vergata", ESRF Beamline BM8 - GILDA _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
I have some time today. I can work on this and see what can be done. I will post my findings. Carlo On Mon, 24 May 2004, Bruce Ravel wrote:
Mauro,
It is not clear to me why you needed to recompile everything else just because you downgraded perl/Tk. (If the problem is failed dependencies in the .deb files, perhaps Carlo could be persuaded to set the dependencies such that 800.024 is acceptable -- which it is).
After that I decided to recompile everything... bad idea! ifeffit-1.2.5 recompiled fine (no errors appeared in the configure/make/make install process).
*BUT* when I try to recompile horae-034 it crash on determining ifeffit version. In fact, if I run "ifeffit -i" it gives me:
Segmentation fault (Killed, on another machine)
Problems like this usually all lall in the same category -- version conflict. Use commands like "which", "whereis" and "locate" to try to figure out if you have multiple versions either of the ifeffit executable or the ifeffit library. My guess is that the new executable is trying to dynamically link to an old library, or vice versa.
B
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Mauro,
*BUT* when I try to recompile horae-034 it crash on determining ifeffit version. In fact, if I run "ifeffit -i" it gives me:
Segmentation fault (Killed, on another machine)
Does running ifeffit from the command line: ~>ifeffit -i give a segfault? It sounded like it did, but I wasn't completely sure. I'm not sure what '(Killed, on another machine)' means. If the command-line program fails, you can take perl out the equation (sorry you reinstalled perl stuff, but fortunately Debian packages are so good that you can easily uninstall and go back to what you had before <wink>). Next, try a ~>ldd /usr/local/bin/ifeffit which will list what ifeffit is linked with. Is anything obviously wrong there (like does libpgplot.so show up in this list)? Since you're working on a debian system, I will ask whether you installed Ifeffit from source and are using the PGPLOT installed from PGPLOT_install, or are using debian packages for these? If you're using debian packages for Ifeffit or PGPLOT, please remove these and reinstall from source. Paul Fons wrote:
Perhaps it is a good thing to ask here, if the library naming has changed on linux as well. Certainly on the Mac it has. There the dynamic library for pgplot was changed and I saw dynamic linking errors when I tried running the latest version of horae on my home brew setup.
Nope, the library naming has not changed for linux. It probably should change. On MacOSX I named my static PGPLOT library libpgplot_iff.a and built static copies of libpng and zlib as well, renaming them to libpng_iff.a and libz_iff.a. This prevents the link statements from pointing to dynamic versions of libpgplot, libpng, and libz, which might be present (say, from Fink) and which will inevitably fail. That's really only a change to how PGPLOT is set up, but it seems to be the source of many problems. Ifeffit's configuration step is supposed to figure out how to link to PGPLOT, but there can be problems when having dynamic libraries present. --Matt
Great Matt, I FIXED it.
Since you're working on a debian system, I will ask whether you installed Ifeffit from source and are using the PGPLOT installed from PGPLOT_install, or are using debian packages for these? If you're using debian packages for Ifeffit or PGPLOT, please remove these and reinstall from source.
It was exactly a problem with pgplot library. I recompiled pgplot by source
and linked the generated-by-source libpgplot.so
NOTE: In the meantime I have pgplot5 installed as debian package (but it
works too).
Sorry for annoying you with my "distribution" problems.
On the other hand, I would like to propose an upgrade in the "horae_update"
script, that is supporting proxy server to fetch upgrades.
Thanks again,
Mauro.
--
Mauro Rovezzi
On Tuesday 25 May 2004 02:00 am, mauro@rulp.org wrote:
Sorry for annoying you with my "distribution" problems.
Don't apologize. The purpose of the mailing list is so that people can consult community wisdom to solve a problem. From the perspective of a developer, the worst thing that can happen is for someone to give up in frustration. I do all this work, after all, so that people will *use* the codes.
On the other hand, I would like to propose an upgrade in the "horae_update" script, that is supporting proxy server to fetch upgrades.
Great idea. I just took a look at the documentation for perl's LWP package (which is what horae_update uses to make its http requests). Although proxy servers seem to be supported, it is unclear to me how it works. Are you will to be my tester, Mauro? B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
On Tue, May 25, 2004 at 09:28:51AM -0400, Bruce Ravel wrote:
On Tuesday 25 May 2004 02:00 am, mauro@rulp.org wrote:
On the other hand, I would like to propose an upgrade in the "horae_update" script, that is supporting proxy server to fetch upgrades.
Great idea. I just took a look at the documentation for perl's LWP package (which is what horae_update uses to make its http requests). Although proxy servers seem to be supported, it is unclear to me how it works.
Are you will to be my tester, Mauro?
Sure! With great pleasure :)
Mauro
--
Mauro Rovezzi
Bruce wrote:
Mauro wrote:
On the other hand, I would like to propose an upgrade in the "horae_update" script, that is supporting proxy server to fetch upgrades.
Great idea. I just took a look at the documentation for perl's LWP package (which is what horae_update uses to make its http requests). Although proxy servers seem to be supported, it is unclear to me how it works.
Would it be good enough to allow the user to select where to download the tarball from, and rely on the Sourceforge mirrors? --Matt
On Tuesday 25 May 2004 11:03 am, Matt Newville wrote:
Bruce wrote:
Mauro wrote:
On the other hand, I would like to propose an upgrade in the "horae_update" script, that is supporting proxy server to fetch upgrades.
Great idea. I just took a look at the documentation for perl's LWP package (which is what horae_update uses to make its http requests). Although proxy servers seem to be supported, it is unclear to me how it works.
Would it be good enough to allow the user to select where to download the tarball from, and rely on the Sourceforge mirrors?
That would certainly be much more robust than sending the traffic to my web site, but I don't see how it mitigates the problem of getting the horae_update script to connect to a local proxy. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Hi,
Would it be good enough to allow the user to select where to download the tarball from, and rely on the Sourceforge mirrors?
That would certainly be much more robust than sending the traffic to my web site, but I don't see how it mitigates the problem of getting the horae_update script to connect to a local proxy.
I was wondering whether the original question was really asking for supporting web proxies or was simply asking for more download sites. I think having more potential download sites and letting a user decide which one to use might be good enough. If a user wanted to, they could put the tarball on their own web server and easily point to that site from multiple nearby machines. I don't have a very good idea of how many people would want to do tha (how many groups are keeping horae running on multiple Unix machines???), but it would be possible. I'd guess more people are running these programs on multiple Windows machines. The updater seems to be OK for that, but perhaps there should be more download sites for the Windows updates as well? --Matt
On Tuesday 25 May 2004 05:19 pm, Matt Newville wrote:
I was wondering whether the original question was really asking for supporting web proxies or was simply asking for more download sites.
Mauro's original question was indeed about web proxies, as a followup, private conversation confirmed. Using perl's LWP::UserAgent, it turns out to be quite easy to handle proxies in roll-your-own web client programs. Mauro gave it a test for me and said it worked properly. I then implemented your other suggestion, which was to use SourceForge. Thanks, great idea! It seems to work fine from my limited testing. I was thinking of putting it on my web page so people could try it out for the next release. Drop me a line if you'd like to try it out right now. I don't know how to get SourceForge to multiplex a request to the (nearest | least busy | whatever) mirror, but I did put in a command line argument allowing the user to specify one of five mirrors. (Side question that I could not find on the SF web site, how many mirrors are there and can anyone provide a link to the complete list? It bugs me that I did not see any mirrors in Asia, Australia, or South America.)
I think having more potential download sites and letting a user decide which one to use might be good enough. If a user wanted to, they could put the tarball on their own web server and easily point to that site from multiple nearby machines.
This final point is intriguing. Is there anyone running multiple unix machines who is interested in doing what Matt suggests? It would not be hard to implement, but I may not bother unless someone thinks they'll use it. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
On Tue, May 25, 2004 at 05:47:25PM -0400, Bruce Ravel wrote:
On Tuesday 25 May 2004 05:19 pm, Matt Newville wrote:
I was wondering whether the original question was really asking for supporting web proxies or was simply asking for more download sites. ?
Mauro's original question was indeed about web proxies, as a followup, private conversation confirmed. Using perl's LWP::UserAgent, it turns out to be quite easy to handle proxies in roll-your-own web client programs. Mauro gave it a test for me and said it worked properly.
I then implemented your other suggestion, which was to use SourceForge. Thanks, great idea! It seems to work fine from my limited testing. I was thinking of putting it on my web page so people could try it out for the next release. Drop me a line if you'd like to try it out right now.
I have checked the --proxy and --mirror options, they work fine.
M
--
Mauro Rovezzi
participants (5)
-
Bruce Ravel
-
Carlo U. Segre
-
Matt Newville
-
mauro@rulp.org
-
Paul Fons