Dear All, Has anybody struggled with compiling version 44.26 and having trouble when compiling with the xdr I am getting messages like
src/su/lib/fgettr.c:148: undefined reference to `xdr_float'
src/su/lib/fputtr.c:123: undefined reference to `xdr_vector'
I am running Ubuntu 22.04 and somehow, although xdr.h is installed at rpc/xdr.h I am not sure why the compiler does not locate it.
Anu suggestions.
Hi,
I did have this problem earlier this year and wrestled with the codes for a while before I decided to ditch xdr support. Probably not the answer you were looking for … but it does work !!
Regards
Rob
From: Ramon Carbonell ramon.carbonell@csic.es Sent: Tuesday, 14 March, 2023 5:16 PM To: seisunix@mailman.seismic-unix.org Subject: [Seisunix] Compilation probles wis dist CWP-44.26
Dear All,
Has anybody struggled with compiling version 44.26 and having trouble when compiling with the xdr
I am getting messages like
src/su/lib/fgettr.c:148: undefined reference to `xdr_float'
src/su/lib/fputtr.c:123: undefined reference to `xdr_vector'
I am running Ubuntu 22.04 and somehow, although xdr.h is installed at rpc/xdr.h
I am not sure why the compiler does not locate it.
Anu suggestions.
Hi This is an old problem with ubuntu. There is no xdr problem with debian and fedora.
So, one solution is to use ubuntu specific linking instruction (see Paul Fertser's message, that I transfered to the list), an other one is to compile SU with an other distro or to "ditch xdr" like Rob...
D.
Le 14 mars 2023 20:57:22 GMT+01:00, rob@xsgeo.com a écrit :
Hi,
I did have this problem earlier this year and wrestled with the codes for a while before I decided to ditch xdr support. Probably not the answer you were looking for … but it does work !!
Regards
Rob
From: Ramon Carbonell ramon.carbonell@csic.es Sent: Tuesday, 14 March, 2023 5:16 PM To: seisunix@mailman.seismic-unix.org Subject: [Seisunix] Compilation probles wis dist CWP-44.26
Dear All,
Has anybody struggled with compiling version 44.26 and having trouble when compiling with the xdr
I am getting messages like
src/su/lib/fgettr.c:148: undefined reference to `xdr_float'
src/su/lib/fputtr.c:123: undefined reference to `xdr_vector'
I am running Ubuntu 22.04 and somehow, although xdr.h is installed at rpc/xdr.h
I am not sure why the compiler does not locate it.
Anu suggestions.
--
Ramon
Ramon Carbonell
CSIC-GEO3BCN GeoSciences Barcelona (http://Geo3BCN.csic.es/ http://Geo3BCN.csic.es ) https://orcid.org/0000-0003-2019-1214 https://orcid.org/0000-0003-2019-1214
Hi SU Pros
Just a suggestion:
Have you tried to install the Ubuntu NFS packages? XDR is part of remote procedure calls (rpc), which is part of NFS.
In Ubuntu 22.04 the main packages are nfs-common (client) and nfs-kernel-server (server) (sudo apt install nfs-common nfs-kernel-server). You don't necessarily need to enable or start the NFS services, if you don't want to use NFS, though.
In particular the xdr_float and xdr_vector functions are part of libtirpc.{a,so}, and the respective function prototypes are part of the xdr.h header file. I can confirm that they do exist in Ubuntu 22.04 (where I installed NFS).
I haven't built and used SU in a while, so the suggestion above is not tested.
I would also guess that the same problem would happen in other Linux distributions, if NFS (or at least RPC) is not installed.
You may get away installing only the libtirpc library packages (transport independent remote procedure calls), but I am not sure. NFS should install it as a dependency.
My two cents, Gus Correa
On Tue, Mar 14, 2023 at 4:47 PM Dominique Rousset < dominique.rousset@univ-pau.fr> wrote:
Hi This is an old problem with ubuntu. There is no xdr problem with debian and fedora.
So, one solution is to use ubuntu specific linking instruction (see Paul Fertser's message, that I transfered to the list), an other one is to compile SU with an other distro or to "ditch xdr" like Rob...
D.
Le 14 mars 2023 20:57:22 GMT+01:00, rob@xsgeo.com a écrit :
Hi,
I did have this problem earlier this year and wrestled with the codes for a while before I decided to ditch xdr support. Probably not the answer you were looking for … but it does work !!
Regards
Rob
*From:* Ramon Carbonell ramon.carbonell@csic.es *Sent:* Tuesday, 14 March, 2023 5:16 PM *To:* seisunix@mailman.seismic-unix.org *Subject:* [Seisunix] Compilation probles wis dist CWP-44.26
Dear All,
Has anybody struggled with compiling version 44.26 and having trouble when compiling with the xdr
I am getting messages like
src/su/lib/fgettr.c:148: undefined reference to `xdr_float'
src/su/lib/fputtr.c:123: undefined reference to `xdr_vector'
I am running Ubuntu 22.04 and somehow, although xdr.h is installed at rpc/xdr.h
I am not sure why the compiler does not locate it.
Anu suggestions.
--
Ramon
Ramon Carbonell
CSIC-GEO3BCN GeoSciences Barcelona (http://Geo3BCN.csic.es/) https://orcid.org/0000-0003-2019-1214
-- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Hi,
On Tue, Mar 14, 2023 at 09:47:04PM +0100, Dominique Rousset wrote:
This is an old problem with ubuntu. There is no xdr problem with debian and fedora.
There will be pretty soon: https://packages.debian.org/search?suite=bookworm&searchon=contents&...
Those RPC functions were removed from glibc, so on any modern GNU/Linux system one just needs to use libtirpc or probably libntirpc. And the current best way to find the right flags for external libraries on modern *nix systems (including FreeBSD) is pkg-config utility. If no library is needed then the calls I'm proposing would return nothing, so my current understanding is that they should be added to Makefile.config upstream. And _ISOC99_SOURCE define is needed for isfinite().
Let's stop and think if we need XDR in SU. At the beginning SU used native endian and floating point format. Users knew that when moving from one computer to another, byte swap and floating point format might be needed. SU was developed on a VAX at Stanford and when I took it to CSM on a compute Gould there there was a factor of 4 in the floating point numbers. Later people lived with moving data between big and small endians, it was sometimes a nuisance but not nearly as much of a problem as XDR is now. Because SU can be compiled with or without XDR, usually without the users being aware of it, there is often a situation that people on the same type of computer are incompatible. Aegrescit medendo.
What I suggest is
1. Back out SU off XDR. Go back to pre XDR gettr and puttr. I may still have an old version of SU but it's simple. 2. Provide diagnostic tools, based on magic ( https://linux.die.net/man/5/magic) to identify narive format SU files 3. Provide either data conversion tools and/or functionality in gettr to convert the data to native format--we don't need XDR to do that. 4. The unsigned short ns header word limits the number of samples per trace to 65K. This was plenty in 1975 when SEGY was new but not now. If somebody simplifies SU taking it off XDR then they can easily designate a fall back 32 bit header word to be used if ns is set to zero.
--- Shuki
On Wed, Mar 15, 2023 at 10:10 AM Paul Fertser fercerpav@gmail.com wrote:
Hi,
On Tue, Mar 14, 2023 at 09:47:04PM +0100, Dominique Rousset wrote:
This is an old problem with ubuntu. There is no xdr problem with debian
and
fedora.
There will be pretty soon:
https://packages.debian.org/search?suite=bookworm&searchon=contents&...
Those RPC functions were removed from glibc, so on any modern GNU/Linux system one just needs to use libtirpc or probably libntirpc. And the current best way to find the right flags for external libraries on modern *nix systems (including FreeBSD) is pkg-config utility. If no library is needed then the calls I'm proposing would return nothing, so my current understanding is that they should be added to Makefile.config upstream. And _ISOC99_SOURCE define is needed for isfinite().
-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Hi All, Thanks all for the reminder about the idiosyncracies of Ubuntu. But, just to add 2c to the discussion, like quite a number of other people and companies (including work at CSM) , I've been using SU interactively mixed with java, which latter writes native bigendian floats. It was a joy to enable the XDR versions of SU where I didn't have to worry about endianity all the time, and scripts didn't need to be littered with swapbytes stuff. So I'd urge caution in removing functionality that many have appreciated immensely. Thanks James.
James Gunning CSIRO Clayton, Vic., Australia ________________________________ From: Shuki Ronen shuki.ronen@gmail.com Sent: Thursday, 16 March 2023 5:31 AM To: seisunix@mailman.seismic-unix.org seisunix@mailman.seismic-unix.org Subject: [Seisunix] Re: Compilation probles wis dist CWP-44.26
Let's stop and think if we need XDR in SU. At the beginning SU used native endian and floating point format. Users knew that when moving from one computer to another, byte swap and floating point format might be needed. SU was developed on a VAX at Stanford and when I took it to CSM on a compute Gould there there was a factor of 4 in the floating point numbers. Later people lived with moving data between big and small endians, it was sometimes a nuisance but not nearly as much of a problem as XDR is now. Because SU can be compiled with or without XDR, usually without the users being aware of it, there is often a situation that people on the same type of computer are incompatible. Aegrescit medendo.
What I suggest is
1. Back out SU off XDR. Go back to pre XDR gettr and puttr. I may still have an old version of SU but it's simple. 2. Provide diagnostic tools, based on magic (https://linux.die.net/man/5/magic) to identify narive format SU files 3. Provide either data conversion tools and/or functionality in gettr to convert the data to native format--we don't need XDR to do that. 4. The unsigned short ns header word limits the number of samples per trace to 65K. This was plenty in 1975 when SEGY was new but not now. If somebody simplifies SU taking it off XDR then they can easily designate a fall back 32 bit header word to be used if ns is set to zero.
--- Shuki
On Wed, Mar 15, 2023 at 10:10 AM Paul Fertser <fercerpav@gmail.commailto:fercerpav@gmail.com> wrote: Hi,
On Tue, Mar 14, 2023 at 09:47:04PM +0100, Dominique Rousset wrote:
This is an old problem with ubuntu. There is no xdr problem with debian and fedora.
There will be pretty soon: https://packages.debian.org/search?suite=bookworm&searchon=contents&...
Those RPC functions were removed from glibc, so on any modern GNU/Linux system one just needs to use libtirpc or probably libntirpc. And the current best way to find the right flags for external libraries on modern *nix systems (including FreeBSD) is pkg-config utility. If no library is needed then the calls I'm proposing would return nothing, so my current understanding is that they should be added to Makefile.config upstream. And _ISOC99_SOURCE define is needed for isfinite().
-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.commailto:fercerpav@gmail.com _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.orgmailto:seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.orgmailto:seisunix-leave@mailman.seismic-unix.org
Okay, this is the first time I hear that people want XDR. So we can't back out of it. --- Shuki
On Wed, Mar 15, 2023 at 3:15 PM Gunning, James (Energy, Clayton North) < James.Gunning@csiro.au> wrote:
Hi All, Thanks all for the reminder about the idiosyncracies of Ubuntu. But, just to add 2c to the discussion, like quite a number of other people and companies (including work at CSM) , I've been using SU interactively mixed with java, which latter writes native bigendian floats. It was a joy to enable the XDR versions of SU where I didn't have to worry about endianity all the time, and scripts didn't need to be littered with swapbytes stuff. So I'd urge caution in removing functionality that many have appreciated immensely. Thanks James.
James Gunning CSIRO Clayton, Vic., Australia
*From:* Shuki Ronen shuki.ronen@gmail.com *Sent:* Thursday, 16 March 2023 5:31 AM *To:* seisunix@mailman.seismic-unix.org <seisunix@mailman.seismic-unix.org
*Subject:* [Seisunix] Re: Compilation probles wis dist CWP-44.26
Let's stop and think if we need XDR in SU. At the beginning SU used native endian and floating point format. Users knew that when moving from one computer to another, byte swap and floating point format might be needed. SU was developed on a VAX at Stanford and when I took it to CSM on a compute Gould there there was a factor of 4 in the floating point numbers. Later people lived with moving data between big and small endians, it was sometimes a nuisance but not nearly as much of a problem as XDR is now. Because SU can be compiled with or without XDR, usually without the users being aware of it, there is often a situation that people on the same type of computer are incompatible. Aegrescit medendo.
What I suggest is
- Back out SU off XDR. Go back to pre XDR gettr and puttr. I may still
have an old version of SU but it's simple. 2. Provide diagnostic tools, based on magic ( https://linux.die.net/man/5/magic) to identify narive format SU files 3. Provide either data conversion tools and/or functionality in gettr to convert the data to native format--we don't need XDR to do that. 4. The unsigned short ns header word limits the number of samples per trace to 65K. This was plenty in 1975 when SEGY was new but not now. If somebody simplifies SU taking it off XDR then they can easily designate a fall back 32 bit header word to be used if ns is set to zero.
--- Shuki
On Wed, Mar 15, 2023 at 10:10 AM Paul Fertser fercerpav@gmail.com wrote:
Hi,
On Tue, Mar 14, 2023 at 09:47:04PM +0100, Dominique Rousset wrote:
This is an old problem with ubuntu. There is no xdr problem with debian
and
fedora.
There will be pretty soon:
https://packages.debian.org/search?suite=bookworm&searchon=contents&...
Those RPC functions were removed from glibc, so on any modern GNU/Linux system one just needs to use libtirpc or probably libntirpc. And the current best way to find the right flags for external libraries on modern *nix systems (including FreeBSD) is pkg-config utility. If no library is needed then the calls I'm proposing would return nothing, so my current understanding is that they should be added to Makefile.config upstream. And _ISOC99_SOURCE define is needed for isfinite().
-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Dear All,
I have been able to compile CWP-44.R26 with the changes in the Makefile.config
I have added as suggested:
POSTLFLAGS = -ltirpc
OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -D_ISOC99_SOURCE CFLAGS = -I$I $(OPTC) $(CWP_FLAGS) $(shell pkg-config --cflags libtirpc)
THe compilation was successful, However an even more strange thing happens now. The generated executables have an segmentation fault when they are called without arguments eg:
Executing a2b (for example)
nmrc@BlueDawn /home/nmrc/ > a2b zsh: segmentation fault (core dumped) a2b
Nevertheless, with an input file the executable works correctly, Has anybody by any chance encountered this issue before? Any ideas how to solve it?
This behaviour gets worse as grafics (xgraph, xwigb, ximage and their su equivalents don't work even with arguments).
suximage perc=98 < tst.su
/home/nmrc/sys.r/sft.local/CWP/bin/ximage: error reading input file zsh: segmentation fault (core dumped) suximage perc=98 < tst.su
Thanks in advance.
Ramon
On Thu, Mar 16, 2023 at 12:43 AM Shuki Ronen shuki.ronen@gmail.com wrote:
Okay, this is the first time I hear that people want XDR. So we can't back out of it. --- Shuki
On Wed, Mar 15, 2023 at 3:15 PM Gunning, James (Energy, Clayton North) < James.Gunning@csiro.au> wrote:
Hi All, Thanks all for the reminder about the idiosyncracies of Ubuntu. But, just to add 2c to the discussion, like quite a number of other people and companies (including work at CSM) , I've been using SU interactively mixed with java, which latter writes native bigendian floats. It was a joy to enable the XDR versions of SU where I didn't have to worry about endianity all the time, and scripts didn't need to be littered with swapbytes stuff. So I'd urge caution in removing functionality that many have appreciated immensely. Thanks James.
James Gunning CSIRO Clayton, Vic., Australia
*From:* Shuki Ronen shuki.ronen@gmail.com *Sent:* Thursday, 16 March 2023 5:31 AM *To:* seisunix@mailman.seismic-unix.org < seisunix@mailman.seismic-unix.org> *Subject:* [Seisunix] Re: Compilation probles wis dist CWP-44.26
Let's stop and think if we need XDR in SU. At the beginning SU used native endian and floating point format. Users knew that when moving from one computer to another, byte swap and floating point format might be needed. SU was developed on a VAX at Stanford and when I took it to CSM on a compute Gould there there was a factor of 4 in the floating point numbers. Later people lived with moving data between big and small endians, it was sometimes a nuisance but not nearly as much of a problem as XDR is now. Because SU can be compiled with or without XDR, usually without the users being aware of it, there is often a situation that people on the same type of computer are incompatible. Aegrescit medendo.
What I suggest is
- Back out SU off XDR. Go back to pre XDR gettr and puttr. I may
still have an old version of SU but it's simple. 2. Provide diagnostic tools, based on magic ( https://linux.die.net/man/5/magic) to identify narive format SU files 3. Provide either data conversion tools and/or functionality in gettr to convert the data to native format--we don't need XDR to do that. 4. The unsigned short ns header word limits the number of samples per trace to 65K. This was plenty in 1975 when SEGY was new but not now. If somebody simplifies SU taking it off XDR then they can easily designate a fall back 32 bit header word to be used if ns is set to zero.
--- Shuki
On Wed, Mar 15, 2023 at 10:10 AM Paul Fertser fercerpav@gmail.com wrote:
Hi,
On Tue, Mar 14, 2023 at 09:47:04PM +0100, Dominique Rousset wrote:
This is an old problem with ubuntu. There is no xdr problem with debian
and
fedora.
There will be pretty soon:
https://packages.debian.org/search?suite=bookworm&searchon=contents&...
Those RPC functions were removed from glibc, so on any modern GNU/Linux system one just needs to use libtirpc or probably libntirpc. And the current best way to find the right flags for external libraries on modern *nix systems (including FreeBSD) is pkg-config utility. If no library is needed then the calls I'm proposing would return nothing, so my current understanding is that they should be added to Makefile.config upstream. And _ISOC99_SOURCE define is needed for isfinite().
-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Hi,
On Fri, Mar 17, 2023 at 10:36:08AM +0100, Ramon Carbonell wrote:
I have been able to compile CWP-44.R26 with the changes in the Makefile.config I have added as suggested: POSTLFLAGS = -ltirpc
I suggest to use pkg-config for linking flags too, not hardcode just the library name.
The generated executables have an segmentation fault when they are called without arguments
...
I thought that's an expected behaviour but if it's a regression I'll try to fix it, thank you for reporting.
Hi,
On Fri, Mar 17, 2023 at 10:36:08AM +0100, Ramon Carbonell wrote:
I have been able to compile CWP-44.R26 with the changes in the Makefile.config
...
OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -D_ISOC99_SOURCE
...
The generated executables have an segmentation fault when they are called
I found the reason to be combination of -std=c99 with features from POSIX, so another macro should be defined instead, please try with these changes:
diff --git a/src/Makefile.config b/src/Makefile.config index a1b8699c11e2..67a628b90329 100644 --- a/src/Makefile.config +++ b/src/Makefile.config @@ -68,7 +68,7 @@ RANFLAGS = ICHMODLINE = chmod 644 $@ MCHMODLINE = chmod 755 $@
-POSTLFLAGS = +POSTLFLAGS = $(shell pkg-config --libs libtirpc)
#----------------------------------------------------------------------- # use both X11 path conventions @@ -92,8 +92,8 @@ CPP = /usr/bin/cpp CC = /usr/bin/gcc #OPTC = -g -c90 -m64 -Wall -ansi -Wno-long-long #OPTC = -g -std=c90 -m64 -Wall -ansi -Wno-long-long -OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -CFLAGS = -I$I $(OPTC) $(CWP_FLAGS) +OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -D_POSIX_C_SOURCE=200112L +CFLAGS = -I$I $(OPTC) $(CWP_FLAGS) $(shell pkg-config --cflags libtirpc)
With this I can't reproduce any segfaults. Please report if there're any other problems left.
Attached is 44R27 please try this
cwp_su_all_44R27.tgz https://drive.google.com/file/d/14stVdfrWDLSiDCSuRKxFdly8xRysQmRb/view?usp=drive_web
On Fri, Mar 17, 2023 at 10:04 AM Paul Fertser fercerpav@gmail.com wrote:
Hi,
On Fri, Mar 17, 2023 at 10:36:08AM +0100, Ramon Carbonell wrote:
I have been able to compile CWP-44.R26 with the changes in the
Makefile.config ...
OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -D_ISOC99_SOURCE
...
The generated executables have an segmentation fault when they are
called
I found the reason to be combination of -std=c99 with features from POSIX, so another macro should be defined instead, please try with these changes:
diff --git a/src/Makefile.config b/src/Makefile.config index a1b8699c11e2..67a628b90329 100644 --- a/src/Makefile.config +++ b/src/Makefile.config @@ -68,7 +68,7 @@ RANFLAGS = ICHMODLINE = chmod 644 $@ MCHMODLINE = chmod 755 $@
-POSTLFLAGS = +POSTLFLAGS = $(shell pkg-config --libs libtirpc)
#----------------------------------------------------------------------- # use both X11 path conventions @@ -92,8 +92,8 @@ CPP = /usr/bin/cpp CC = /usr/bin/gcc #OPTC = -g -c90 -m64 -Wall -ansi -Wno-long-long #OPTC = -g -std=c90 -m64 -Wall -ansi -Wno-long-long -OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -CFLAGS = -I$I $(OPTC) $(CWP_FLAGS) +OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -D_POSIX_C_SOURCE=200112L +CFLAGS = -I$I $(OPTC) $(CWP_FLAGS) $(shell pkg-config --cflags libtirpc)
With this I can't reproduce any segfaults. Please report if there're any other problems left.
-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Dear All,
I am retaking the issues with regard to a segmentation error that happens on SU modules after successful compilation. I have been compiling and testing several releases of CWP-44 versions on UBUNTU 22.04 LTS. The issue is that after successful compilation when I try and run any of the modules, an immediate segmentation error occurs, and the documentation is not printed out. when using the debugger, I get always the same message independently of the executable ( a2b, sunan, etc). ------------------------------------------------------------------------------------------- Program received signal SIGSEGV, Segmentation fault. __vfprintf_internal (s=0x555642a0, format=0x55555555c292 "%s\n", ap=ap@entry=0x7fffffffbe50, mode_flags=mode_flags@entry=0) at ./stdio-common/vfprintf-internal.c:1218 1218 ./stdio-common/vfprintf-internal.c: No such file or directory. (gdb) where #0 __vfprintf_internal (s=0x555642a0, format=0x55555555c292 "%s\n", ap=ap@entry=0x7fffffffbe50, mode_flags=mode_flags@entry=0) at ./stdio-common/vfprintf-internal.c:1218 #1 0x00007ffff7c6074a in __fprintf (stream=<optimized out>, format=<optimized out>) at ./stdio-common/fprintf.c:32 #2 0x0000555555556b2d in pagedoc () at docpkge.c:126 #3 0x0000555555556a09 in requestdoc (flag=1) at docpkge.c:95 #4 0x00005555555567e6 in main (argc=1, argv=0x7fffffffc118) at a2b.c:55 ------------------------------------------------------------------------------------------------------------
However the problem starts at release R20, Up to R19 the entire CWP-SU works OK, no segmentation errors, form R20 onwards the distributions are useless on UBUNTU 22.04 LTS. (I have tried on 3 different machines to make sure it was not a set up issue).
CWP-44.R18 fine CWP-44.R19 fine CWP-44.R20 segmentation errors CWP-44.R22 segmentation errors CWP-44.R25 segmentation errors CWP-44.R26 segmentation errors CWP-44.R27 segmentation errors
If anybody has any idea It would be welcome. Thanks.
On Fri, Mar 17, 2023 at 10:36 AM Ramon Carbonell ramon.carbonell@csic.es wrote:
Dear All,
I have been able to compile CWP-44.R26 with the changes in the Makefile.config
I have added as suggested:
POSTLFLAGS = -ltirpc
OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -D_ISOC99_SOURCE CFLAGS = -I$I $(OPTC) $(CWP_FLAGS) $(shell pkg-config --cflags libtirpc)
THe compilation was successful, However an even more strange thing happens now. The generated executables have an segmentation fault when they are called without arguments eg:
Executing a2b (for example)
nmrc@BlueDawn /home/nmrc/ > a2b zsh: segmentation fault (core dumped) a2b
Nevertheless, with an input file the executable works correctly, Has anybody by any chance encountered this issue before? Any ideas how to solve it?
This behaviour gets worse as grafics (xgraph, xwigb, ximage and their su equivalents don't work even with arguments).
suximage perc=98 < tst.su
/home/nmrc/sys.r/sft.local/CWP/bin/ximage: error reading input file zsh: segmentation fault (core dumped) suximage perc=98 < tst.su
Thanks in advance.
Ramon
On Thu, Mar 16, 2023 at 12:43 AM Shuki Ronen shuki.ronen@gmail.com wrote:
Okay, this is the first time I hear that people want XDR. So we can't back out of it. --- Shuki
On Wed, Mar 15, 2023 at 3:15 PM Gunning, James (Energy, Clayton North) < James.Gunning@csiro.au> wrote:
Hi All, Thanks all for the reminder about the idiosyncracies of Ubuntu. But, just to add 2c to the discussion, like quite a number of other people and companies (including work at CSM) , I've been using SU interactively mixed with java, which latter writes native bigendian floats. It was a joy to enable the XDR versions of SU where I didn't have to worry about endianity all the time, and scripts didn't need to be littered with swapbytes stuff. So I'd urge caution in removing functionality that many have appreciated immensely. Thanks James.
James Gunning CSIRO Clayton, Vic., Australia
*From:* Shuki Ronen shuki.ronen@gmail.com *Sent:* Thursday, 16 March 2023 5:31 AM *To:* seisunix@mailman.seismic-unix.org < seisunix@mailman.seismic-unix.org> *Subject:* [Seisunix] Re: Compilation probles wis dist CWP-44.26
Let's stop and think if we need XDR in SU. At the beginning SU used native endian and floating point format. Users knew that when moving from one computer to another, byte swap and floating point format might be needed. SU was developed on a VAX at Stanford and when I took it to CSM on a compute Gould there there was a factor of 4 in the floating point numbers. Later people lived with moving data between big and small endians, it was sometimes a nuisance but not nearly as much of a problem as XDR is now. Because SU can be compiled with or without XDR, usually without the users being aware of it, there is often a situation that people on the same type of computer are incompatible. Aegrescit medendo.
What I suggest is
- Back out SU off XDR. Go back to pre XDR gettr and puttr. I may
still have an old version of SU but it's simple. 2. Provide diagnostic tools, based on magic ( https://linux.die.net/man/5/magic) to identify narive format SU files 3. Provide either data conversion tools and/or functionality in gettr to convert the data to native format--we don't need XDR to do that. 4. The unsigned short ns header word limits the number of samples per trace to 65K. This was plenty in 1975 when SEGY was new but not now. If somebody simplifies SU taking it off XDR then they can easily designate a fall back 32 bit header word to be used if ns is set to zero.
--- Shuki
On Wed, Mar 15, 2023 at 10:10 AM Paul Fertser fercerpav@gmail.com wrote:
Hi,
On Tue, Mar 14, 2023 at 09:47:04PM +0100, Dominique Rousset wrote:
This is an old problem with ubuntu. There is no xdr problem with
debian and
fedora.
There will be pretty soon:
https://packages.debian.org/search?suite=bookworm&searchon=contents&...
Those RPC functions were removed from glibc, so on any modern GNU/Linux system one just needs to use libtirpc or probably libntirpc. And the current best way to find the right flags for external libraries on modern *nix systems (including FreeBSD) is pkg-config utility. If no library is needed then the calls I'm proposing would return nothing, so my current understanding is that they should be added to Makefile.config upstream. And _ISOC99_SOURCE define is needed for isfinite().
-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
-- Ramon
Ramon Carbonell CSIC-GEO3BCN GeoSciences Barcelona (http://Geo3BCN.csic.es/) https://orcid.org/0000-0003-2019-1214
Hello,
On Thu, Mar 23, 2023 at 10:30:39AM +0100, Ramon Carbonell wrote:
CWP-44.R27 segmentation errors If anybody has any idea It would be welcome. Thanks.
Is that R27 without any changes? Are you sure you were compiling with -D_POSIX_C_SOURCE=200112L and not -D_ISOC99_SOURCE?
I'm pretty sure I can fix the segfaults but I need a way to reproduce it on my machine or an ssh access to host where it shows...
On Thu, Mar 23, 2023 at 10:30:39AM +0100, Ramon Carbonell wrote:
CWP-44.R27 segmentation errors If anybody has any idea It would be welcome. Thanks.
I was using non-distro specific Makefile.config with the changes I am proposing, and it wasn't segfaulting. I see R27 added some ubuntu-specific config, and it's not using pkg-config, and the macro defined is -D_POSIX_SOURCE, not -D_POSIX_C_SOURCE=200112L , this last point might make a difference.
In general I think distro-specific Makefiles shouldn't be used, and instead pkg-config and other auto-detection methods should take care of all the differences (just few if any are really essential for SU) between all GNU/Linux distros.
I need a way to reproduce, if it still segfaults please show log of all your actions (downloading, configuring, making, running).
Dear Paul,
Finally following your suggestions in last email, it work, many thanks for the help I am attaching the Makefile.config (if it can help any body handling R27 and running on UBUNTU 22.04 LTS)
On Thu, Mar 23, 2023 at 11:25 AM Paul Fertser fercerpav@gmail.com wrote:
On Thu, Mar 23, 2023 at 10:30:39AM +0100, Ramon Carbonell wrote:
CWP-44.R27 segmentation errors If anybody has any idea It would be welcome. Thanks.
I was using non-distro specific Makefile.config with the changes I am proposing, and it wasn't segfaulting. I see R27 added some ubuntu-specific config, and it's not using pkg-config, and the macro defined is -D_POSIX_SOURCE, not -D_POSIX_C_SOURCE=200112L , this last point might make a difference.
In general I think distro-specific Makefiles shouldn't be used, and instead pkg-config and other auto-detection methods should take care of all the differences (just few if any are really essential for SU) between all GNU/Linux distros.
I need a way to reproduce, if it still segfaults please show log of all your actions (downloading, configuring, making, running).
-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com
Hello Ramon,
On Thu, Mar 23, 2023 at 12:04:02PM +0100, Ramon Carbonell wrote:
Finally following your suggestions in last email, it work, many thanks for the help
Glad to hear!
On a more general topic, I would be happy to help your community more with my *nix software engineering skills. So if you have more segfaults or weird compatibility issues or anything else related to report, please do.
seisunix@mailman.seismic-unix.org
-
Dominique Rousset -
Gunning, James (Energy, Clayton North) -
Gus Correa -
John Stockwell -
Paul Fertser -
Ramon Carbonell -
rob＠xsgeo.com -
Shuki Ronen