You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(6) |
Nov
(9) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(6) |
Feb
(6) |
Mar
(13) |
Apr
(10) |
May
(4) |
Jun
(5) |
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(7) |
Dec
(8) |
2002 |
Jan
(3) |
Feb
(6) |
Mar
(2) |
Apr
(8) |
May
(4) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
(15) |
Nov
(4) |
Dec
(2) |
2003 |
Jan
(5) |
Feb
(9) |
Mar
(8) |
Apr
(6) |
May
(1) |
Jun
(7) |
Jul
(10) |
Aug
|
Sep
(7) |
Oct
(11) |
Nov
(3) |
Dec
(6) |
2004 |
Jan
(15) |
Feb
(7) |
Mar
(5) |
Apr
|
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(1) |
2005 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2006 |
Jan
(9) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
(10) |
Jun
(45) |
Jul
(65) |
Aug
(62) |
Sep
(62) |
Oct
(25) |
Nov
(1) |
Dec
(11) |
2007 |
Jan
(25) |
Feb
(22) |
Mar
(15) |
Apr
(18) |
May
(9) |
Jun
(9) |
Jul
(59) |
Aug
(20) |
Sep
(1) |
Oct
(11) |
Nov
(6) |
Dec
(1) |
2008 |
Jan
(1) |
Feb
(15) |
Mar
(38) |
Apr
(3) |
May
(14) |
Jun
(3) |
Jul
(19) |
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(6) |
2009 |
Jan
(27) |
Feb
(28) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(11) |
Oct
(2) |
Nov
(9) |
Dec
(5) |
2010 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(1) |
May
(6) |
Jun
(13) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2011 |
Jan
|
Feb
(7) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(10) |
Dec
(7) |
2012 |
Jan
(8) |
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
(41) |
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2014 |
Jan
|
Feb
(6) |
Mar
(46) |
Apr
|
May
(3) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2015 |
Jan
(1) |
Feb
(1) |
Mar
(16) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
(17) |
2016 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
(12) |
May
(15) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(17) |
Oct
(3) |
Nov
|
Dec
(6) |
2017 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(13) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(2) |
Dec
(4) |
2018 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(17) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Michele D. <md...@gm...> - 2018-07-27 17:55:02
|
On 07/26/18 15:40, Stuart Levy wrote: > In the make.log section you sent, the first real error (as opposed to > warning) is at: > > GeomExportFunc *export; > > The C compiler is complaining about "export" as if it were a C > reserved word. It didn't use to be, but maybe is now. > > Actually it seems to be a rarely-implemented-and-now-deprecated * C++ > * keyword, but maybe the version of gcc or clang or whatever you're > using considers it to be a C keyword anyway. Actually I notice line 246 of the Makefile is CC = g++ Is that right? Shouldn't it be CC=gcc? It also says CXX=g++. > > Can you tell what compiler you are using? # gcc --version gcc (GCC) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # > I guess you just took the latter section out of the make.log, so it > doesn't mention the compile command. That's as far back as my terminal buffer goes. If I say gmake > foo, all I get is: gmake all-recursive gmake[1]: Entering directory '/export/home/denber/geomview-1.9.5' Making all in src gmake[2]: Entering directory '/export/home/denber/geomview-1.9.5/src' Making all in lib gmake[3]: Entering directory '/export/home/denber/geomview-1.9.5/src/lib' Making all in geometry gmake[4]: Entering directory '/export/home/denber/geomview-1.9.5/src/lib/geometry' Making all in cmodel gmake[5]: Entering directory '/export/home/denber/geomview-1.9.5/src/lib/geometry/cmodel' /bin/bash ../../../../libtool --tag=CC --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -g -O2 -MT cm_geometry.lo -MD -MP -MF .deps/cm_geometry.Tpo -c -o cm_geometry.lo cm_geometry.c libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -g -O2 -MT cm_geometry.lo -MD -MP -MF .deps/cm_geometry.Tpo -c cm_geometry.c -fPIC -DPIC -o .libs/cm_geometry.o gmake[5]: Leaving directory '/export/home/denber/geomview-1.9.5/src/lib/geometry/cmodel' gmake[4]: Leaving directory '/export/home/denber/geomview-1.9.5/src/lib/geometry' gmake[3]: Leaving directory '/export/home/denber/geomview-1.9.5/src/lib' gmake[2]: Leaving directory '/export/home/denber/geomview-1.9.5/src' gmake[1]: Leaving directory '/export/home/denber/geomview-1.9.5' > > When you say that setting LDFLAGS didn't make any difference, the > place I would expect to see the difference is either of two: > > - in the Makefile that's generated in the directory where the > geomview (gvx?) executable will be. Does that Makefile mention -lnsl > or -lsocket or both? Four places: LDFLAGS = -lsocket SOCKETLIBS = XLIBS = -L/usr/openwin/lib -R/usr/openwin/lib -lSM -lICE -lXt -lXext -lX11 -lnsl X_EXTRA_LIBS = -lnsl > > - in the make.log, but only if the build process gets far enough > to try to link something. It won't show up in a make.log section > like the one you included. And if the compilation runs into an > error, like this one does, it will stop while it's still trying to > compile (turning source files into object files) but before it gets to > linking (combining the .o object files and .a libraries into a final > execuable file). > > Changing the LDFLAGS or library settings won't change the compilation > steps, only the linking steps. > > In comparison, changing the include-files ( -I/usr/local/whatnot with > a dash-capital-eye ) *does* affect the compilation steps. I tried gmake -I/usr/local/include but got the same errors. - Michele |
From: Stuart L. <sa...@il...> - 2018-07-27 17:17:59
|
In the make.log section you sent, the first real error (as opposed to warning) is at: GeomExportFunc *export; The C compiler is complaining about "export" as if it were a C reserved word. It didn't use to be, but maybe is now. Actually it seems to be a rarely-implemented-and-now-deprecated * C++ * keyword, but maybe the version of gcc or clang or whatever you're using considers it to be a C keyword anyway. Can you tell what compiler you are using? I guess you just took the latter section out of the make.log, so it doesn't mention the compile command. When you say that setting LDFLAGS didn't make any difference, the place I would expect to see the difference is either of two: - in the Makefile that's generated in the directory where the geomview (gvx?) executable will be. Does that Makefile mention -lnsl or -lsocket or both? - in the make.log, but only if the build process gets far enough to try to link something. It won't show up in a make.log section like the one you included. And if the compilation runs into an error, like this one does, it will stop while it's still trying to compile (turning source files into object files) but before it gets to linking (combining the .o object files and .a libraries into a final execuable file). Changing the LDFLAGS or library settings won't change the compilation steps, only the linking steps. In comparison, changing the include-files ( -I/usr/local/whatnot with a dash-capital-eye ) *does* affect the compilation steps. On 07/26/2018 01:56 PM, Michele Denber wrote: > >> >> >> >> >> >> typo on my part, sorry; the #ifdef () should just be an #if (), since we're testing >> values, not if a name has been defined. >> Will likely still fail for a different reason, though. > Right you are, it did. See attached make log. In fact it's a > completely different set of errors now, none of which I understand. > "Okay, attached is the bit of your configure output we care about, > relating to socket use. > > the autoconf configure script detects that passing -lsocket > as a flag to the linker is needed, so that should be somewhere. > but since this is now autoconf generated, it's messy. If you edit the > configure script that generates the makefile, and search for > socket, you will see that it already looks for sys/socket.h - > could try changing that to #include </usr/include/sys/socket.h> > and rerunning?" > I did - I'm still getting the same weird errors, same as the attached > log file. > > " Stuart points out that Solaris used to use -nsl instead of > -lsocket. So you could try adding that too as a flag to where > the linker is invoked before making - though I suspect this > old flag might be supported by Solaris CC and not gcc? > > The Oracle Solaris 11.3 docs we've looked at on http://docs.oracle.com > suggest that dynamic linking to libsocket.so should suffice - but surely > one of the flags should do that?" > ' > > I tried setting LDFLAGS to -nsl, -lsocket, and "-nsl -lsocket". None > of that made any difference. > > - Michele > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > geomview-users mailing list > geo...@li... > https://lists.sourceforge.net/lists/listinfo/geomview-users |
From: Michele D. <md...@gm...> - 2018-07-26 18:55:40
|
> > > > > > > typo on my part, sorry; the #ifdef () should just be an #if (), since we're testing > values, not if a name has been defined. > Will likely still fail for a different reason, though. Right you are, it did. See attached make log. In fact it's a completely different set of errors now, none of which I understand. "Okay, attached is the bit of your configure output we care about, relating to socket use. the autoconf configure script detects that passing -lsocket as a flag to the linker is needed, so that should be somewhere. but since this is now autoconf generated, it's messy. If you edit the configure script that generates the makefile, and search for socket, you will see that it already looks for sys/socket.h - could try changing that to #include</usr/include/sys/socket.h> and rerunning?" I did - I'm still getting the same weird errors, same as the attached log file. " Stuart points out that Solaris used to use -nsl instead of -lsocket. So you could try adding that too as a flag to where the linker is invoked before making - though I suspect this old flag might be supported by Solaris CC and not gcc? The Oracle Solaris 11.3 docs we've looked at onhttp://docs.oracle.com suggest that dynamic linking to libsocket.so should suffice - but surely one of the flags should do that?" ' I tried setting LDFLAGS to -nsl, -lsocket, and "-nsl -lsocket". None of that made any difference. - Michele |
From: <llo...@ya...> - 2018-07-25 02:45:47
|
Michele typo on my part, sorry; the #ifdef () should just be an #if (), since we're testing values, not if a name has been defined. Will likely still fail for a different reason, though. Okay, attached is the bit of your configure output we care about, relating to socket use. the autoconf configure script detects that passing -lsocket as a flag to the linker is needed, so that should be somewhere. but since this is now autoconf generated, it's messy. If you edit the configure script that generates the makefile, and search for socket, you will see that it already looks for sys/socket.h - could try changing that to #include </usr/include/sys/socket.h> and rerunning? Stuart points out that Solaris used to use -nsl instead of -lsocket. So you could try adding that too as a flag to where the linker is invoked before making - though I suspect this old flag might be supported by Solaris CC and not gcc? The Oracle Solaris 11.3 docs we've looked at on http://docs.oracle.com suggest that dynamic linking to libsocket.so should suffice - but surely one of the flags should do that? hope this helps Lloyd Wood http://savi.sf.net On Wednesday, 25 July 2018, 02:53:49 GMT+10, Michele Denber <md...@gm...> wrote: On 07/23/18 12:52, Michele Denber wrote: > Michele > > since gmake install is now complaining about comm.o, that suggests > that my patch to comm.c was not the right thing to do. > > Some possibilities here: > - The INET stuff expects listenOps to be defined somewhere else, > so it's only added in comm.c for UNIX sockets. But Solaris doesn't see it? > It's implicitly defined in a non-included header, so > #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) > #include whatever-that-header-is.h > #endif > at start of comm.c might work? > Unfortunately, no. I added in comm.c: #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) #include /usr/include/sys/socket.h #endif and got: cc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -I.. -g -c -o comm.o comm.c comm.c:23:8: error: macro names must be identifiers #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) ^ gmake[5]: *** [Makefile:437: comm.o] Error 1 No idea what that means. > > > - configure decided on INET when it should have picked UNIX? > So, forgetting my previous change and doing > #def HAVE_UNIX_SOCKETS 1 > ? > Well in config.h, HAVE_INET_SOCKETS and HAVE_INET6_SOCKETS were both definted to 1 but HAVE_UNIX_SOCKETS was not. So I deinfed UNIX and tried again. Didn't work. > > What version of Solaris are you using? > Solaris 10, update 11. > > (and when did gmake > start being the default on Slowlaris? > When Sun went out of business and stopped updating their software :-( Sure you can still get support from Oracle, but not being Bill Gates or the Sultan of Brunai, that's out of my league. > > Whatever happened to > Solaris Studio/CC? > Oh I have that too. Didn't work either. > > That might have something to do with UNIX/INET confusion?) > uname -a > # uname -a SunOS canadice 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise # > > What does configure think about your system? > cd geomview-1.9.5 > ./configure > capture.log > > and send capture.log as an attachment > Attached. I've been pulling my hair out for a day now over this. The undefined symbols come from libsocket.so and I do have that in /usr/lib/. But for the life of me I can't get geomview to look there. Maybe I'm just doing something wrong so simple I can't see it. - Michele |
From: Michele D. <md...@gm...> - 2018-07-24 16:53:19
|
On 07/23/18 12:52, Michele Denber wrote: > > Michele > > since gmake install is now complaining about comm.o, that suggests > that my patch to comm.c was not the right thing to do. > > Some possibilities here: > - The INET stuff expects listenOps to be defined somewhere else, > so it's only added in comm.c for UNIX sockets. But Solaris doesn't see it? > It's implicitly defined in a non-included header, so > #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) > #include whatever-that-header-is.h > #endif > at start of comm.c might work? Unfortunately, no. I added in comm.c: #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) #include /usr/include/sys/socket.h #endif and got: cc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -I.. -g -c -o comm.o comm.c comm.c:23:8: error: macro names must be identifiers #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) ^ gmake[5]: *** [Makefile:437: comm.o] Error 1 No idea what that means. > > > - configure decided on INET when it should have picked UNIX? > So, forgetting my previous change and doing > #def HAVE_UNIX_SOCKETS 1 > ? Well in config.h, HAVE_INET_SOCKETS and HAVE_INET6_SOCKETS were both definted to 1 but HAVE_UNIX_SOCKETS was not. So I deinfed UNIX and tried again. Didn't work. > > What version of Solaris are you using? Solaris 10, update 11. > (and when did gmake > start being the default on Slowlaris? When Sun went out of business and stopped updating their software :-( Sure you can still get support from Oracle, but not being Bill Gates or the Sultan of Brunai, that's out of my league. > Whatever happened to > Solaris Studio/CC? Oh I have that too. Didn't work either. > That might have something to do with UNIX/INET confusion?) > uname -a # uname -a SunOS canadice 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise # > What does configure think about your system? > cd geomview-1.9.5 > ./configure> capture.log > > and send capture.log as an attachment Attached. I've been pulling my hair out for a day now over this. The undefined symbols come from libsocket.so and I do have that in /usr/lib/. But for the life of me I can't get geomview to look there. Maybe I'm just doing something wrong so simple I can't see it. - Michele |
From: Stuart L. <sa...@il...> - 2018-07-23 01:55:36
|
Since it compiles, but common network functions bind() and accept() are undefined, I think that means that the header files are reasonable but there's a missing -l (dash-ell) library. Long ago "-lnsl" was the right thing for Solaris for network functions, but not any more apparently. This page says that for socket functions (bind() and accept() should be among those) one should link with the library: -lsocket Can someone see where in the Makefiles -lnsl gets specified, and replace it with-lsocket ? On 07/22/2018 07:52 PM, Lloyd Wood via geomview-users wrote: > Michele > > since gmake install is now complaining about comm.o, that suggests > that my patch to comm.c was not the right thing to do. > > Some possibilities here: > - The INET stuff expects listenOps to be defined somewhere else, > so it's only added in comm.c for UNIX sockets. But Solaris doesn't see it? > It's implicitly defined in a non-included header, so > #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) > #include whatever-that-header-is.h > #endif > at start of comm.c might work? > > > - configure decided on INET when it should have picked UNIX? > So, forgetting my previous change and doing > #def HAVE_UNIX_SOCKETS 1 > ? > > What version of Solaris are you using? (and when did gmake > start being the default on Slowlaris? Whatever happened to > Solaris Studio/CC? That might have something to do with UNIX/INET confusion?) > uname -a > What does configure think about your system? > cd geomview-1.9.5 > ./configure > capture.log > > and send capture.log as an attachment > > thanks and regards > > Lloyd Wood > http://savi.sf.net > > > On Monday, 23 July 2018, 02:49:32 GMT+10, Michele Denber <md...@gm...> wrote: > > > Thanks very much Lloyd. Your patch worked fine and gmake has completed without error. > > Unfortunately, now gmake install isn't happy: > > ... > gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/x11' > (echo 'char builddate[] = "'"`date +%Y%m%d%H%M`"'";'; \ > echo 'char buildinfo1[] = "'" By `whoami`@`hostname`[`uname -s`-`uname -r`]"'";'; \ > echo 'char buildinfo2[] = "'" On `date`"'";'; \ > ) > buildinfo.c > gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -I/usr/openwin/include -I.. -g -O2 -MT buildinfo.o -MD -MP -MF .deps/buildinfo.Tpo -c -o buildinfo.o buildinfo.c > mv -f .deps/buildinfo.Tpo .deps/buildinfo.Po > /bin/bash ../../../../libtool --tag=CC --mode=link gcc -g -O2 -o gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o ../common/libgvcommon.a buildinfo.o ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/libgeomview.la -L/usr/openwin/lib -R/usr/openwin/lib -lSM -lICE -lXt -lXext -lX11 -lnsl -lm > libtool: link: gcc -g -O2 -o .libs/gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o buildinfo.o ../common/libgvcommon.a ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/.libs/libgeomview.so -L/usr/openwin/lib -L/usr/local/lib -lGL -lGLU -lz -lSM -lICE -lXt -lXext -lX11 -lnsl -lm -R/usr/local/lib -R/usr/openwin/lib > Undefined first referenced > symbol in file > bind ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) > accept ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) > listen ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) > socket ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) > ld: fatal: symbol referencing errors. No output written to .libs/gvx > gmake[5]: *** [Makefile:494: gvx] Error 1 > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > geomview-users mailing list > geo...@li... > https://lists.sourceforge.net/lists/listinfo/geomview-users |
From: Lloyd W. <ecl...@ya...> - 2018-07-23 00:53:03
|
Michele since gmake install is now complaining about comm.o, that suggests that my patch to comm.c was not the right thing to do. Some possibilities here: - The INET stuff expects listenOps to be defined somewhere else, so it's only added in comm.c for UNIX sockets. But Solaris doesn't see it? It's implicitly defined in a non-included header, so #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) #include whatever-that-header-is.h #endif at start of comm.c might work? - configure decided on INET when it should have picked UNIX? So, forgetting my previous change and doing #def HAVE_UNIX_SOCKETS 1 ? What version of Solaris are you using? (and when did gmake start being the default on Slowlaris? Whatever happened to Solaris Studio/CC? That might have something to do with UNIX/INET confusion?) uname -a What does configure think about your system? cd geomview-1.9.5 ./configure > capture.log and send capture.log as an attachment thanks and regards Lloyd Wood http://savi.sf.net On Monday, 23 July 2018, 02:49:32 GMT+10, Michele Denber <md...@gm...> wrote: Thanks very much Lloyd. Your patch worked fine and gmake has completed without error. Unfortunately, now gmake install isn't happy: ... gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/x11' (echo 'char builddate[] = "'"`date +%Y%m%d%H%M`"'";'; \ echo 'char buildinfo1[] = "'" By `whoami`@`hostname`[`uname -s`-`uname -r`]"'";'; \ echo 'char buildinfo2[] = "'" On `date`"'";'; \ ) > buildinfo.c gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -I/usr/openwin/include -I.. -g -O2 -MT buildinfo.o -MD -MP -MF .deps/buildinfo.Tpo -c -o buildinfo.o buildinfo.c mv -f .deps/buildinfo.Tpo .deps/buildinfo.Po /bin/bash ../../../../libtool --tag=CC --mode=link gcc -g -O2 -o gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o ../common/libgvcommon.a buildinfo.o ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/libgeomview.la -L/usr/openwin/lib -R/usr/openwin/lib -lSM -lICE -lXt -lXext -lX11 -lnsl -lm libtool: link: gcc -g -O2 -o .libs/gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o buildinfo.o ../common/libgvcommon.a ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/.libs/libgeomview.so -L/usr/openwin/lib -L/usr/local/lib -lGL -lGLU -lz -lSM -lICE -lXt -lXext -lX11 -lnsl -lm -R/usr/local/lib -R/usr/openwin/lib Undefined first referenced symbol in file bind ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) accept ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) listen ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) socket ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) ld: fatal: symbol referencing errors. No output written to .libs/gvx gmake[5]: *** [Makefile:494: gvx] Error 1 |
From: Michele D. <md...@gm...> - 2018-07-22 16:49:18
|
Thanks very much Lloyd. Your patch worked fine and gmake has completed without error. Unfortunately, now gmake install isn't happy: ... gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/x11' (echo 'char builddate[] = "'"`date +%Y%m%d%H%M`"'";'; \ echo 'char buildinfo1[] = "'" By `whoami`@`hostname`[`uname -s`-`uname -r`]"'";'; \ echo 'char buildinfo2[] = "'" On `date`"'";'; \ ) > buildinfo.c gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -I/usr/openwin/include -I.. -g -O2 -MT buildinfo.o -MD -MP -MF .deps/buildinfo.Tpo -c -o buildinfo.o buildinfo.c mv -f .deps/buildinfo.Tpo .deps/buildinfo.Po /bin/bash ../../../../libtool --tag=CC --mode=link gcc -g -O2 -o gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o ../common/libgvcommon.a buildinfo.o ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/libgeomview.la -L/usr/openwin/lib -R/usr/openwin/lib -lSM -lICE -lXt -lXext -lX11 -lnsl -lm libtool: link: gcc -g -O2 -o .libs/gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o buildinfo.o ../common/libgvcommon.a ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/.libs/libgeomview.so -L/usr/openwin/lib -L/usr/local/lib -lGL -lGLU -lz -lSM -lICE -lXt -lXext -lX11 -lnsl -lm -R/usr/local/lib -R/usr/openwin/lib Undefined first referenced symbol in file bind ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) accept ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) listen ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) socket ../common/libgvcommon.a(comm.o) (symbol belongs to implicit dependency /lib/libsocket.so.1) ld: fatal: symbol referencing errors. No output written to .libs/gvx gmake[5]: *** [Makefile:494: gvx] Error 1 |
From: <llo...@us...> - 2018-07-22 02:50:37
|
(adding in the geomview mailing lists) Hi Michele, The last time I used Geomview on a Sparc it was a Sparc20 in the year 2000... but this looks like a clear bug in Geomview to me >From code inspection of geomview/src/bin/geomview/common/comm.c I see that listenOps is defined in the chunk of code if you have unix sockets: #if HAVE_UNIX_SOCKETS static handleOps listenOps = blah de blah #endif but it is referenced in three chunks of code later on: #if HAVE_UNIX_SOCKETS #endif #if HAVE_INET_SOCKETS #endif #if HAVE_INET6_SOCKETS #endif and from line 1659, you're failing in the HAVE_INET_SOCKETS case, so the Solaris networking stack has changed in the last eighteen years. But the code would never have worked for any inet non-unix sockets anyway? I think the fix to this is to change the initial #ifdef HAVE_UNIX_SOCKETS to #ifdef (HAVE_UNIX_SOCKETS || HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS) so that listenOps is always defined, as shown in the attached diff; I think the assumption here is that Geomview is still supposed to work if no networking stack is present without defining or running any of these (though I don't know how X works if no networking stack is present). But I have not been able to test this, and I'd like an opinion on this from Geomview developers before they commit a fix to the codebase. Your feedback on whether the attached diff works would be appreciated. cp comm.c comm.c.backup patch comm.c < comm-mod.diff thanks and regards Lloyd Wood http://savi.sf.net On Sunday, 22 July 2018, 05:50:05 GMT+10, Michele Denber <mic...@us...> wrote: I hope this is in the right place. While building Geomview 1.9.5 on a Sun Oracle Enterprise M3000 SPARC64 VII running Solaris 10U11, opencsw toolchain, gcc 4.9.2, I ran ./configure which completed without error. But then gmake gave: ~~~ ... Making all in geomview gmake[4]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview' Making all in . gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview' ../../../src/lib/oogl/lisp/lisp2c -cprefix "gv_" -o clang ./common/*.c ./x11/*.cgmake[5]: Leaving directory '/export/home/michele/geomview-1.9.5/src/bin/geomview' Making all in common gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/common' gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -I.. -g -O2 -MT comm.o -MD -MP -MF .deps/comm.Tpo -c -o comm.o comm.c comm.c: In function ‘usepipe’: comm.c:1659:63: error: ‘listenOps’ undeclared (first use in this function) Pool *p = PoolStreamOpen(pipename, fdopen(s, "rb"), 0, &listenOps); ^ comm.c:1659:63: note: each undeclared identifier is reported only once for each function it appears in gmake[5]: *** [Makefile:435: comm.o] Error 1 gmake[5]: Leaving directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/common' gmake[4]: *** [Makefile:483: all-recursive] Error 1 gmake[4]: Leaving directory '/export/home/michele/geomview-1.9.5/src/bin/geomview' gmake[3]: *** [Makefile:406: all-recursive] Error 1 gmake[3]: Leaving directory '/export/home/michele/geomview-1.9.5/src/bin' gmake[2]: *** [Makefile:473: all-recursive] Error 1 gmake[2]: Leaving directory '/export/home/michele/geomview-1.9.5/src' gmake[1]: *** [Makefile:540: all-recursive] Error 1 gmake[1]: Leaving directory '/export/home/michele/geomview-1.9.5' gmake: *** [Makefile:429: all] Error 2 ~~~ --- [Solaris 10 build fails with error: ‘listenOps’ undeclared](https://sourceforge.net/p/geomview/discussion/134473/thread/ee3c4a35/?limit=25#1f08) --- Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/geomview/discussion/134473/> To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/> |
From: Snedden, A. <Ali...@na...> - 2018-03-23 08:46:20
|
Thank you for the information. I will give this a try. Even simply running glxinfo fails with the same error. From: Lloyd Wood <llo...@ya...<mailto:llo...@ya...>> Reply-To: Lloyd Wood <llo...@ya...<mailto:llo...@ya...>> Date: Friday, March 23, 2018 at 1:51 AM To: Mark Phillips <mb...@ge...<mailto:mb...@ge...>>, Snedden Ali <Ali...@na...<mailto:Ali...@na...>> Cc: "geo...@li...<mailto:geo...@li...>" <geo...@li...<mailto:geo...@li...>> Subject: Re: [geomview-users] Difficulty loading swrast driver [WARNING: External Email - Use Caution] libGL error: failed to load driver: swrast often appears related to mesa conflicting with nvidia drivers, which have to be reinstalled every time a kernel update is done. And it's a GL problem; Geomview just uses OpenGL. See e.g. https://www.centos.org/forums/viewtopic.php?t=56273<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_forums_viewtopic.php-3Ft-3D56273&d=DwMFaQ&c=FGzDrZ8hK6OoO1oc9Smc5l64O0n3B5aByDFzrvN9KLI&r=sYzXEOLE0nIGb8FZXZ4rzqcWzLgnZJS81SxbG89PYGcR31pru1BY9l2GBCwPyFaz&m=x8aY3SpsQ2DanPBWZH3MWvVQCyfETelmQBj4lRTrzHI&s=VEZozrSVjV_TIbYWsX7xEtJoqOQkkuC7digUStQVU_4&e=> https://bugzilla.redhat.com/show_bug.cgi?id=1093323<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1093323&d=DwMFaQ&c=FGzDrZ8hK6OoO1oc9Smc5l64O0n3B5aByDFzrvN9KLI&r=sYzXEOLE0nIGb8FZXZ4rzqcWzLgnZJS81SxbG89PYGcR31pru1BY9l2GBCwPyFaz&m=x8aY3SpsQ2DanPBWZH3MWvVQCyfETelmQBj4lRTrzHI&s=0AZb29lC7P9xwH6whwnY-lbV4RfIO829hWxulLbQUos&e=> and try > rpm -e mesa-libGL.i686 --nodeps > rpm -e mesa-libGL.x86_64 --nodeps Geomview tends to live slightly better on Debian/Ubuntu; I've always found CentOS to be a lot of configuration work. Lloyd Wood http://savi.sf.net/<https://urldefense.proofpoint.com/v2/url?u=http-3A__savi.sf.net_&d=DwMFaQ&c=FGzDrZ8hK6OoO1oc9Smc5l64O0n3B5aByDFzrvN9KLI&r=sYzXEOLE0nIGb8FZXZ4rzqcWzLgnZJS81SxbG89PYGcR31pru1BY9l2GBCwPyFaz&m=x8aY3SpsQ2DanPBWZH3MWvVQCyfETelmQBj4lRTrzHI&s=8UxcKlgmIz_ou-5DcuALW8Do_7ly8R662ZZrZx9xF6U&e=> ________________________________ From: Mark Phillips <mb...@ge...<mailto:mb...@ge...>> To: "Snedden, Ali" <Ali...@na...<mailto:Ali...@na...>> Cc: "geo...@li...<mailto:geo...@li...>" <geo...@li...<mailto:geo...@li...>> Sent: Friday, 23 March 2018, 0:30 Subject: Re: [geomview-users] Difficulty loading swrast driver This is just a wild guess but I wonder if the error has something to do with your video drivers. Have you been able to run any other programs that use GL? Maybe try updating your video drivers? On Thu, Mar 22, 2018 at 8:41 AM, Snedden, Ali <Ali...@na...<mailto:Ali...@na...>> wrote: I am working on a CentOS 6.6 cluster and trying to get Geomview to work. It appeared to install without error. > > >From the tutorial : > > >qmaster02: ~$ geomview tetra dodec >libGL error: failed to load driver: swrast >X Error of failed request: BadValue (integer parameter out of range for operation) > Major opcode of failed request: 149 (GLX) > Minor opcode of failed request: 3 (X_GLXCreateContext) > Value in failed request: 0x0 > Serial number of failed request: 1224 > Current serial number in output stream: 1227 > > >Ok, so I figured maybe there is a problem in the shared library: > > >qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/ libgeomview.so >linux-vdso.so.1 => (0x00007fff897c9000) >libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000) >libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000) >libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000) >libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000) >libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000) >libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000) >libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000) >libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000) >libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000) >libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000) >libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000) >libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000) >libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000) >libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000) >libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000) >libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000) >libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000) >libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000) >libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000) >libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000) >libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000) >libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000) >libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++ .so.6 (0x00002b732251d000) >libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s. so.1 (0x00002b732282f000) >libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000) >/lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000) >libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000) >librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000) > > >It appears that all the libraries are found. I also looked at > > >ldd /opt/geomview-1.9.5/libexec/ geomview/gvx >ldd /opt/geomview-1.9.5/libexec/ geomview/nose > > >and it appears that there aren’t any missing libraries. I also looked at the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any missing libraries. > > >Question : How do I solve this error? > > > > >Thanks, >Ali |
From: Lloyd W. <llo...@ya...> - 2018-03-23 05:51:43
|
libGL error: failed to load driver: swrast often appears related to mesa conflicting with nvidia drivers, which have to be reinstalled every time a kernel update is done. And it's a GL problem; Geomview just uses OpenGL. See e.g. https://www.centos.org/forums/viewtopic.php?t=56273 https://bugzilla.redhat.com/show_bug.cgi?id=1093323 and try > rpm -e mesa-libGL.i686 --nodeps > rpm -e mesa-libGL.x86_64 --nodeps Geomview tends to live slightly better on Debian/Ubuntu; I've always found CentOS to be a lot of configuration work. Lloyd Wood http://savi.sf.net/ ________________________________ From: Mark Phillips <mb...@ge...> To: "Snedden, Ali" <Ali...@na...> Cc: "geo...@li..." <geo...@li...> Sent: Friday, 23 March 2018, 0:30 Subject: Re: [geomview-users] Difficulty loading swrast driver This is just a wild guess but I wonder if the error has something to do with your video drivers. Have you been able to run any other programs that use GL? Maybe try updating your video drivers? On Thu, Mar 22, 2018 at 8:41 AM, Snedden, Ali <Ali...@na...> wrote: I am working on a CentOS 6.6 cluster and trying to get Geomview to work. It appeared to install without error. > > >From the tutorial : > > >qmaster02: ~$ geomview tetra dodec >libGL error: failed to load driver: swrast >X Error of failed request: BadValue (integer parameter out of range for operation) > Major opcode of failed request: 149 (GLX) > Minor opcode of failed request: 3 (X_GLXCreateContext) > Value in failed request: 0x0 > Serial number of failed request: 1224 > Current serial number in output stream: 1227 > > >Ok, so I figured maybe there is a problem in the shared library: > > >qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/ libgeomview.so >linux-vdso.so.1 => (0x00007fff897c9000) >libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000) >libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000) >libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000) >libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000) >libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000) >libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000) >libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000) >libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000) >libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000) >libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000) >libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000) >libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000) >libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000) >libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000) >libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000) >libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000) >libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000) >libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000) >libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000) >libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000) >libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000) >libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000) >libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++ .so.6 (0x00002b732251d000) >libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s. so.1 (0x00002b732282f000) >libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000) >/lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000) >libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000) >librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000) > > >It appears that all the libraries are found. I also looked at > > >ldd /opt/geomview-1.9.5/libexec/ geomview/gvx >ldd /opt/geomview-1.9.5/libexec/ geomview/nose > > >and it appears that there aren’t any missing libraries. I also looked at the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any missing libraries. > > >Question : How do I solve this error? > > > > >Thanks, >Ali |
From: Mark P. <mb...@ge...> - 2018-03-22 13:29:36
|
This is just a wild guess but I wonder if the error has something to do with your video drivers. Have you been able to run any other programs that use GL? Maybe try updating your video drivers? On Thu, Mar 22, 2018 at 8:41 AM, Snedden, Ali < Ali...@na...> wrote: > I am working on a CentOS 6.6 cluster and trying to get Geomview to work. > It appeared to install without error. > > From the tutorial : > > qmaster02: ~$ geomview tetra dodec > > libGL error: failed to load driver: swrast > > X Error of failed request: BadValue (integer parameter out of range for > operation) > > Major opcode of failed request: 149 (GLX) > > Minor opcode of failed request: 3 (X_GLXCreateContext) > > Value in failed request: 0x0 > > Serial number of failed request: 1224 > > Current serial number in output stream: 1227 > > Ok, so I figured maybe there is a problem in the shared library: > > qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/libgeomview.so > > linux-vdso.so.1 => (0x00007fff897c9000) > > libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000) > > libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000) > > libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000) > > libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000) > > libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000) > > libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000) > > libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000) > > libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000) > > libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000) > > libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000) > > libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000) > > libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000) > > libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000) > > libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000) > > libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000) > > libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000) > > libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000) > > libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000) > > libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000) > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000) > > libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000) > > libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000) > > libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++.so.6 (0x00002b732251d000) > > libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s.so.1 (0x00002b732282f000) > > libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000) > > /lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000) > > libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000) > > librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000) > > It appears that all the libraries are found. I also looked at > > ldd /opt/geomview-1.9.5/libexec/geomview/gvx > > ldd /opt/geomview-1.9.5/libexec/geomview/nose > > > and it appears that there aren’t any missing libraries. I also looked at > the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any > missing libraries. > > Question : How do I solve this error? > > > Thanks, > Ali > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > geomview-users mailing list > geo...@li... > https://lists.sourceforge.net/lists/listinfo/geomview-users > > |
From: Snedden, A. <Ali...@na...> - 2018-03-22 12:44:42
|
I also looked at the libGL libraries themselves and it appears that all the libraries are still found E.g. qmaster02: ~$ ldd /usr/lib64/libGL.so.1 linux-vdso.so.1 => (0x00007fff43bef000) libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002ade209f0000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002ade20c18000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002ade20e2a000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002ade2102c000) libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002ade21232000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002ade21433000) libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002ade21770000) libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002ade21987000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002ade21b8b000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002ade21da9000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002ade21faf000) libm.so.6 => /lib64/libm.so.6 (0x00002ade221ba000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ade2243e000) libdl.so.2 => /lib64/libdl.so.2 (0x00002ade2265c000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002ade22860000) libc.so.6 => /lib64/libc.so.6 (0x00002ade22a7f000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002ade22e14000) librt.so.1 => /lib64/librt.so.1 (0x00002ade23017000) /lib64/ld-linux-x86-64.so.2 (0x00002ade20547000) Thanks, Ali From: Snedden Ali <Ali...@na...<mailto:Ali...@na...>> Date: Thursday, March 22, 2018 at 8:41 AM To: "geo...@li...<mailto:geo...@li...>" <geo...@li...<mailto:geo...@li...>> Subject: Difficulty loading swrast driver I am working on a CentOS 6.6 cluster and trying to get Geomview to work. It appeared to install without error. From the tutorial : qmaster02: ~$ geomview tetra dodec libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 1224 Current serial number in output stream: 1227 Ok, so I figured maybe there is a problem in the shared library: qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/libgeomview.so linux-vdso.so.1 => (0x00007fff897c9000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000) libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000) libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000) libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000) libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000) libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000) libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000) libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000) libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000) libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000) libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000) libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++.so.6 (0x00002b732251d000) libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s.so.1 (0x00002b732282f000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000) /lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000) librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000) It appears that all the libraries are found. I also looked at ldd /opt/geomview-1.9.5/libexec/geomview/gvx ldd /opt/geomview-1.9.5/libexec/geomview/nose and it appears that there aren’t any missing libraries. I also looked at the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any missing libraries. Question : How do I solve this error? Thanks, Ali |
From: Snedden, A. <Ali...@na...> - 2018-03-22 12:41:11
|
I am working on a CentOS 6.6 cluster and trying to get Geomview to work. It appeared to install without error. From the tutorial : qmaster02: ~$ geomview tetra dodec libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 1224 Current serial number in output stream: 1227 Ok, so I figured maybe there is a problem in the shared library: qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/libgeomview.so linux-vdso.so.1 => (0x00007fff897c9000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000) libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000) libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000) libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000) libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000) libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000) libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000) libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000) libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000) libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000) libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000) libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++.so.6 (0x00002b732251d000) libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s.so.1 (0x00002b732282f000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000) /lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000) librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000) It appears that all the libraries are found. I also looked at ldd /opt/geomview-1.9.5/libexec/geomview/gvx ldd /opt/geomview-1.9.5/libexec/geomview/nose and it appears that there aren’t any missing libraries. I also looked at the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any missing libraries. Question : How do I solve this error? Thanks, Ali |
From: Lloyd W. <llo...@ya...> - 2017-12-18 02:50:28
|
Charlie, Okay, stupid layman question here. Don't qhull and CGAL do delaunay and convex hull calculations? https://academic.oup.com/bib/article/15/1/54/187726 "Several libraries have been established to calculate Delaunay triangulation and alpha shape such as the Qhull [16] and the Computational Geometry Algorithm Library (CGAL) [17]. Qhull is developed by Barber et al. based on the Quickhull algorithm which offers a programmable library to compute the convex hull, Delaunay triangulation and Voronoi diagram. CGAL is an open source project which aims to provide efficient and reliable geometric algorithms. Compared with Qhull, CGAL offers a wider range of geometric computation including polygons, convex hull, Delaunay triangulation, Voronoi diagram, alpha shape and mesh generation." http://www.qhull.org Qhull talks to geomview directly - see links. https://doc.cgal.org/latest/Manual/index.html or you can use PyDeT on PyMol, I suppose... https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2478735/ I'm a bit unclear on how much of the wheel you need to reinvent here, or whether leveraging the tools above could save you a lot of time. Lloyd Wood http://savi.sf.net ________________________________ From: "Carter, Charlie" <ca...@me...> To: "geo...@li..." <geo...@li...> Sent: Saturday, 16 December 2017, 18:10 Subject: [geomview-users] writing a correct geom file Hello out there. I’m not even sure that this list serve still functions. Nonetheless, I’m pretty desperately seeking some way into the club. For many years, I had software developed by a former student to evaluate delaunay tessellations and convex hulls for 3D data sets derived from protein crystal structures. I am a Mac user and with the advent of OSX El Capitan (OSX 10.11.6), that executable no longer functioned, and I’m trying to re-build its functionality using Octave. The trouble I have is that there is no way to visualize what I’m generating using any of the octave commands. Inline plot commands (trisurf) create a plot and then hang; that is apparently a recurrent problem from discussions on the web. I’ve installed geomview hoping to use it instead. However, although I can view any of the examples provided with the installation, I cannot determine how to configure the output files from octave so that they can be recognized by geomview or how to configure convex hull output from Octave into geoms or ool files.. Are there any examples or tutorials out there to help? I used to think that although I am not a programmer, I was pretty savvy with software, but that period was long ago. I have not kept up with anything since Fortran! Any assistance would be much appreciated. Charlie Carter Professor of Biochemistry and Biophysics UNC Chapel Hill |
From: Adrian R. <ad...@an...> - 2017-12-16 07:46:10
|
Hi Charlie On Sat, 16 Dec 2017, Carter, Charlie wrote: > I’ve installed geomview hoping to use it instead. However, although I > can view any of the examples provided with the installation, I cannot > determine how to configure the output files from octave so that they can > be recognized by geomview or how to configure convex hull output from > Octave into geoms or ool files.. Maybe this link is useful https://alexbjorkholm.wordpress.com/2016/10/07/exporting-3d-objects-from-octave/ There is sample code for converting to wavefront OBJ format, which you may be able to pipe through the Antiprism obj2off program (possibly within Octave if that is more convenient) http://www.antiprism.com/programs/obj2off.html The resulting OFF can be viewed in Geomview. If it is of interest, for your visualisation, the Antiprism Antiview program is able to detect the symmetry of your models and display the symmetry elements http://www.antiprism.com/programs/antiview.html Adrian. -- Adrian Rossiter ad...@an... http://antiprism.com/adrian |
From: Carter, C. <ca...@me...> - 2017-12-16 07:10:17
|
Hello out there. I’m not even sure that this list serve still functions. Nonetheless, I’m pretty desperately seeking some way into the club. For many years, I had software developed by a former student to evaluate delaunay tessellations and convex hulls for 3D data sets derived from protein crystal structures. I am a Mac user and with the advent of OSX El Capitan (OSX 10.11.6), that executable no longer functioned, and I’m trying to re-build its functionality using Octave. The trouble I have is that there is no way to visualize what I’m generating using any of the octave commands. Inline plot commands (trisurf) create a plot and then hang; that is apparently a recurrent problem from discussions on the web. I’ve installed geomview hoping to use it instead. However, although I can view any of the examples provided with the installation, I cannot determine how to configure the output files from octave so that they can be recognized by geomview or how to configure convex hull output from Octave into geoms or ool files.. Are there any examples or tutorials out there to help? I used to think that although I am not a programmer, I was pretty savvy with software, but that period was long ago. I have not kept up with anything since Fortran! Any assistance would be much appreciated. Charlie Carter Professor of Biochemistry and Biophysics UNC Chapel Hill |
From: Adrian R. <ad...@an...> - 2017-12-09 06:52:40
|
Hi All Antiprism 0.25.1 polyhedron modelling software has been released https://groups.google.com/d/topic/antiprism/tmFpO_ctj1Y/discussion The programs all work natively with OFF. The new 'wythoff' program (and also 'conway') will lay out repeating polygonal tiling patterns on arbitrary surfaces, e.g. https://groups.google.com/d/msg/geodesichelp/Hr_QJbKx2CI/Nu36-UBdBAAJ Adrian. -- Adrian Rossiter ad...@an... http://antiprism.com/adrian |
From: Lloyd W. <llo...@ya...> - 2017-11-24 05:45:53
|
As Sourceforge CVS stops allowing commits and goes read-only for some indefinite time, I've made copies of everything we have in CVS as tarballs under http://www.geomview.org/dev (This also buys more time for cvs2svn conversion, which is a nice idea in theory, but which I can't make work.) cheers Lloyd Wood http://savi.sf.net ________________________________ From: Lloyd Wood <llo...@ya...> To: Lloyd Wood <llo...@ya...>; Steve Robbins <st...@su...>; "geo...@li..." <geo...@li...> Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...> Sent: Wednesday, 8 November 2017, 7:42 Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017 While saying that github can host active geomview development, there's a bunch of other dormant little things in geomview cvs - maniview, orrery, gv1-modules, the fabled gv2. sourceforge isn't guaranteeing the longevity of read-only cvs, so worth also copying everything over to svn via e.g. a cvs2svn import for longevity/archival? thanks Lloyd Wood http://savi.sf.net/ ________________________________ From: Lloyd Wood via geomview-users <geo...@li...> To: Claus-Justus Heine <hi...@cl...>; Steve Robbins <st...@su...>; "geo...@li..." <geo...@li...> Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...> Sent: Monday, 9 October 2017, 14:38 Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017 Okay, it looks like Mark bringing https://github.com/geomview up to date, then sticking a note in the sourceforge CVS that github is where any current development is at, and my then updating various geomview webpage pointers would be the approach to take. thanks Lloyd Wood http://savi.sf.net ________________________________ From: Claus-Justus Heine <hi...@cl...> To: Steve Robbins <st...@su...>; geo...@li...; Lloyd Wood <llo...@ya...> Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...> Sent: Monday, 9 October 2017, 14:20 Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017 Sorry, being buried in my every day's job activities I will not be able to help much, unfortunately. For practical reasons I would vote for github if I had a vote. Kind thanks for your efforts to keep Geomview alive! Claus Am 09.10.2017 um 05:13 schrieb Steve Robbins: > On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote: > >> thoughts on the approach to take? > > I'm fine with whatever the committers decide -- they are the biggest user of > the source control system. > > If I had a vote, however, I'd place mine on git. Probably github. The main > reason is that I think SVN will similarly die out at some point. For > instance, Debian's forge (alioth) is being replaced and will likely only > support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/ > VCS > > -Steve > -- Claus-Justus Heine hi...@cl... http://www.claus-justus-heine.de/ Schatzmeister der Camerata Academica Freiburg e.V. --- www.cafev.de ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ geomview-users mailing list geo...@li... https://lists.sourceforge.net/lists/listinfo/geomview-users |
From: Lloyd W. <llo...@ya...> - 2017-11-07 20:42:31
|
While saying that github can host active geomview development, there's a bunch of other dormant little things in geomview cvs - maniview, orrery, gv1-modules, the fabled gv2. sourceforge isn't guaranteeing the longevity of read-only cvs, so worth also copying everything over to svn via e.g. a cvs2svn import for longevity/archival? thanks Lloyd Wood http://savi.sf.net/ ________________________________ From: Lloyd Wood via geomview-users <geo...@li...> To: Claus-Justus Heine <hi...@cl...>; Steve Robbins <st...@su...>; "geo...@li..." <geo...@li...> Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...> Sent: Monday, 9 October 2017, 14:38 Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017 Okay, it looks like Mark bringing https://github.com/geomview up to date, then sticking a note in the sourceforge CVS that github is where any current development is at, and my then updating various geomview webpage pointers would be the approach to take. thanks Lloyd Wood http://savi.sf.net ________________________________ From: Claus-Justus Heine <hi...@cl...> To: Steve Robbins <st...@su...>; geo...@li...; Lloyd Wood <llo...@ya...> Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...> Sent: Monday, 9 October 2017, 14:20 Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017 Sorry, being buried in my every day's job activities I will not be able to help much, unfortunately. For practical reasons I would vote for github if I had a vote. Kind thanks for your efforts to keep Geomview alive! Claus Am 09.10.2017 um 05:13 schrieb Steve Robbins: > On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote: > >> thoughts on the approach to take? > > I'm fine with whatever the committers decide -- they are the biggest user of > the source control system. > > If I had a vote, however, I'd place mine on git. Probably github. The main > reason is that I think SVN will similarly die out at some point. For > instance, Debian's forge (alioth) is being replaced and will likely only > support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/ > VCS > > -Steve > -- Claus-Justus Heine hi...@cl... http://www.claus-justus-heine.de/ Schatzmeister der Camerata Academica Freiburg e.V. --- www.cafev.de ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ geomview-users mailing list geo...@li... https://lists.sourceforge.net/lists/listinfo/geomview-users |
From: Claus-Justus H. <hi...@cl...> - 2017-10-09 03:46:05
|
Sorry, being buried in my every day's job activities I will not be able to help much, unfortunately. For practical reasons I would vote for github if I had a vote. Kind thanks for your efforts to keep Geomview alive! Claus Am 09.10.2017 um 05:13 schrieb Steve Robbins: > On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote: > >> thoughts on the approach to take? > > I'm fine with whatever the committers decide -- they are the biggest user of > the source control system. > > If I had a vote, however, I'd place mine on git. Probably github. The main > reason is that I think SVN will similarly die out at some point. For > instance, Debian's forge (alioth) is being replaced and will likely only > support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/ > VCS > > -Steve > -- Claus-Justus Heine hi...@cl... http://www.claus-justus-heine.de/ Schatzmeister der Camerata Academica Freiburg e.V. --- www.cafev.de |
From: Lloyd W. <llo...@ya...> - 2017-10-09 03:38:08
|
Okay, it looks like Mark bringing https://github.com/geomview up to date, then sticking a note in the sourceforge CVS that github is where any current development is at, and my then updating various geomview webpage pointers would be the approach to take. thanks Lloyd Wood http://savi.sf.net ________________________________ From: Claus-Justus Heine <hi...@cl...> To: Steve Robbins <st...@su...>; geo...@li...; Lloyd Wood <llo...@ya...> Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...> Sent: Monday, 9 October 2017, 14:20 Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017 Sorry, being buried in my every day's job activities I will not be able to help much, unfortunately. For practical reasons I would vote for github if I had a vote. Kind thanks for your efforts to keep Geomview alive! Claus Am 09.10.2017 um 05:13 schrieb Steve Robbins: > On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote: > >> thoughts on the approach to take? > > I'm fine with whatever the committers decide -- they are the biggest user of > the source control system. > > If I had a vote, however, I'd place mine on git. Probably github. The main > reason is that I think SVN will similarly die out at some point. For > instance, Debian's forge (alioth) is being replaced and will likely only > support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/ > VCS > > -Steve > -- Claus-Justus Heine hi...@cl... http://www.claus-justus-heine.de/ Schatzmeister der Camerata Academica Freiburg e.V. --- www.cafev.de |
From: Steve R. <st...@su...> - 2017-10-09 03:26:56
|
On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote: > thoughts on the approach to take? I'm fine with whatever the committers decide -- they are the biggest user of the source control system. If I had a vote, however, I'd place mine on git. Probably github. The main reason is that I think SVN will similarly die out at some point. For instance, Debian's forge (alioth) is being replaced and will likely only support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/ VCS -Steve |
From: Larry P. <lp...@co...> - 2017-10-08 19:20:55
|
On Sun, 8 Oct 2017 04:42:33 +0000 (UTC) Lloyd Wood via geomview-users <geo...@li...> wrote: > > thoughts on the approach to take? > As long as it would be possible to download a tarball then it should make no difference. I am not sure, but with git only the source tree can be downloaded while github allows the tree to be packaged into a tarball. Also, does this mean the end of versioned releases? |
From: Lloyd W. <llo...@ya...> - 2017-10-08 04:42:45
|
We've had a long 17-year run out of cvs in SourceForge, but it's now reached end of life, and cvs clients are getting as rare as telnet clients in distros these days (e.g. not in current Mac OS X Xcode). So, geomview has to migrate to a new primary repository, per the SourceForge note below. Mark was playing with github, and could bring that up to date: https://github.com/geomview which is one possibility, as are git on Sourceforge, mercurial on sourceforge -- or even svn on sourceforge, which I'll be looking at migrating SaVi to (as I'm pretty much the only developer there, and mercurial and git are complex configuration overkill for that project and this user. if you're capable of building the development geomview autoconf toolchain, git probably won't cause you too many difficulties.) thoughts on the approach to take? thanks, Lloyd Wood http://savi.sf.net ----- Forwarded Message ----- From: SourceForge Support <cvs...@so...> Sent: Sunday, 8 October 2017, 3:22 Subject: CVS support at SourceForge and Nov. 30 Greetings project admin, We have been planning to discontinue CVS support here at SourceForge for several years now, and that time has finally arrived. Since your project is making use of CVS for your source version control, you should now convert your repository over to another version control system. The current plan is to stop allowing CVS commits by November 30th. To be able to continue making source code changes you’ll need to have your CVS repo converted by then. The ssh access method will stop working, but read-only access via both pserver, rsync, and interactive shell will continue to be available past the cutoff date (we haven’t determined if or when the read-only support will end). This means that you will have plenty of time to convert your data to a new SCM format, even well past the cutoff date. If you don’t have a particular SCM choice in mind, we recommend choosing Subversion (SVN) since it has a workflow that is most similar to that of CVS. You might also want to choose Git, which is very popular these days, though it does have a steeper learning curve compared to switching to Subversion. You can even give each one a try and keep the one you like best. Don’t be afraid to experiment. For information on how to convert your repository from CVS to SVN or Git, visit the following web page: https://sourceforge.net/p/forge/documentation/CVS/ The page also documents the rsync backup method. We hope that your conversion goes smoothly. You can let us know if you run into any issues by replying to this email. Sincerely, SourceForge Support |