geomview-users — Geomview users' discussion list

Re: [geomview-users] SaVi segfaulting when writing to a geomview pipe?

[Adrian R. <ad...@an...>]

Hi Lloyd

On Sat, 15 Jun 2019, llo...@ya... wrote:
> #    DEBUGFLAGS = -Wall -Wextra -Wconversion -pedantic -ansi
>
> The -ansi flag caused SaVi to segfault on writing to the geomview pipe 
> with recent gcc, removing that flag fixed it. But why? gcc 7.3 or later

If you look at the build warnings you will see

gv_utils.c: In function ‘gv_stream_init_proc’:
gv_utils.c:93:11: warning: implicit declaration of function ‘fileno’; did 
you mean ‘fopen’? [-Wimplicit-function-declaration]
    fdout = fileno(stdout);
            ^~~~~~
            fopen

It appears that the solution is to define _POSIX_C_SOURCE, e.g.

    make CC="gcc  -Wall -Wextra -Wconversion -pedantic -ansi -D_POSIX_C_SOURCE" ARCH=ubuntu

The resulting binary then runs correctly.

See here for some explanation

    https://stackoverflow.com/questions/25759672/ansi-c-and-temporary-files

Adrian.
-- 
Adrian Rossiter
ad...@an...
http://antiprism.com/adrian

Re: [geomview-users] SaVi segfaulting when writing to a geomview pipe?

[<llo...@ya...>]

Thanks Adrian and Rajmund, you provided the hints I needed, and I love you.

One change I'd not considered in packaging SaVi for release was turning offgcc debugflags for release in savi-dev/src/Makefile
- this is made manually outside the codetree, i.e. in the release tarball,not in any of my working directories. And I make it, not package maintainers. So 

#    DEBUGFLAGS = -Wall -Wextra -Wconversion -pedantic -ansi

The -ansi flag caused SaVi to segfault on writing to the geomview pipe with recent gcc, removing that flag fixed it. But why? gcc 7.3 or later now seems to crash this (7.3 on Microsoft App Ubuntu, 7.4 on cygwin, 8.3 on Ubuntu 18.10). Haven't tried earlier. Remove -ansi, make clean, make ARCH=whatever and all is well.

Did printing to file get removed from gcc's interpretation of the ansi spec or something?
puzzled

Lloyd Wood
http://savi.sf.net/


On Saturday, 15 June 2019, 19:42:18 GMT+10, Adrian Rossiter <ad...@an...> wrote: 


Hi Lloyd

On Sat, 15 Jun 2019, lloyd.wood--- via geomview-users wrote:
> I'm pretty familiar with and involved in the packaging of SaVi on ubuntu
> and on cygwin, and the changes made are very minor.
>
> Yet geomview -run ./savi-dev/savi now fails on both ubuntu and cygwin,
> while geomview -run savi to run the savi package works just fine. So,
> it's something that has changed elsewhere, not sure what yet.

I just quickly built the Savi 1.5.1 release tarball from Sourceforge
on Ubuntu 18.04, and the program started up fine.


$ geomview -run ./savi

SaVi: selected platform-specific binary 
/home/adrian/proj/programs/savi1.5.1/bin/SaVi-ubuntu.bin

SaVi: compiled without zlib compression.
SaVi: defaulting to J2 orbital model.
SaVi: thankyou for using SaVi.


Adrian.
-- 
Adrian Rossiter
ad...@an...
http://antiprism.com/adrian


_______________________________________________
geomview-users mailing list
geo...@li...
https://lists.sourceforge.net/lists/listinfo/geomview-users

Re: [geomview-users] SaVi segfaulting when writing to a geomview pipe?

[Adrian R. <ad...@an...>]

Hi Lloyd

On Sat, 15 Jun 2019, lloyd.wood--- via geomview-users wrote:
> I'm pretty familiar with and involved in the packaging of SaVi on ubuntu
> and on cygwin, and the changes made are very minor.
>
> Yet geomview -run ./savi-dev/savi now fails on both ubuntu and cygwin,
> while geomview -run savi to run the savi package works just fine. So,
> it's something that has changed elsewhere, not sure what yet.

I just quickly built the Savi 1.5.1 release tarball from Sourceforge
on Ubuntu 18.04, and the program started up fine.

$ geomview -run ./savi
SaVi: selected platform-specific binary 
/home/adrian/proj/programs/savi1.5.1/bin/SaVi-ubuntu.bin

SaVi: compiled without zlib compression.
SaVi: defaulting to J2 orbital model.
SaVi: thankyou for using SaVi.


Adrian.
-- 
Adrian Rossiter
ad...@an...
http://antiprism.com/adrian

Re: [geomview-users] SaVi segfaulting when writing to a geomview pipe?

[<llo...@ya...>]

Thanks for the suggestion.

I'm pretty familiar with and involved in the packaging of SaVi on ubuntu
and on cygwin, and the changes made are very minor.

Yet geomview -run ./savi-dev/savi now fails on both ubuntu and cygwin,
while geomview -run savi to run the savi package works just fine. So,
it's something that has changed elsewhere, not sure what yet.

(Might this be an indication that piping control of geomview needs a
rethink? No idea.)

Lloyd Wood
http://savi.sf.net



On Monday, 10 June 2019, 03:29:03 GMT+10, <raj...@ij...> wrote: 



Try extracting files from the package without installing;
if there are separate patch files, you can see what they
are (and may need to apply them). At least some fedora
packages are like this.

Rajmund

On Sun, 9 Jun 2019, Lloyd Wood via geomview-users wrote:

> I'm dealing with the odd situation on linux where
> geomview -run savi
> works just fine if geomview and savi are installed as
> ubuntu packages, but if I compile savi 1.5.1 (matching
> the package) SaVi segfaults on first attempting to write to the
> pipe to geomview via fprintf.
>
>
> stdout is set up to point to geomview and dup'd, and there's
> a lot of error checking in that code to test for failures
> during setup. Those checks pass, but as soon as you fprintf
> to the pipe - boom, goodbye your compiled savi.
>
>
> This code hasn't changed (ie I'm not smart enough to change
> it) in years...
>
> Has something changed in stdlib or in how file pointers
>
> can be used and abused in gcc? Ideas to investigate  welcome.
>
> thanks
>
> Lloyd Wood
> http://savi.sf.net/

Re: [geomview-users] SaVi segfaulting when writing to a geomview pipe?

[<raj...@ij...>]

Try extracting files from the package without installing;
if there are separate patch files, you can see what they
are (and may need to apply them). At least some fedora
packages are like this.

Rajmund

On Sun, 9 Jun 2019, Lloyd Wood via geomview-users wrote:

> I'm dealing with the odd situation on linux where
> geomview -run savi
> works just fine if geomview and savi are installed as
> ubuntu packages, but if I compile savi 1.5.1 (matching
> the package) SaVi segfaults on first attempting to write to the
> pipe to geomview via fprintf.
>
>
> stdout is set up to point to geomview and dup'd, and there's
> a lot of error checking in that code to test for failures
> during setup. Those checks pass, but as soon as you fprintf
> to the pipe - boom, goodbye your compiled savi.
>
>
> This code hasn't changed (ie I'm not smart enough to change
> it) in years...
>
> Has something changed in stdlib or in how file pointers
>
> can be used and abused in gcc? Ideas to investigate  welcome.
>
> thanks
>
> Lloyd Wood
> http://savi.sf.net/
>
>
> _______________________________________________
> geomview-users mailing list
> geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geomview-users
>

[geomview-users] SaVi segfaulting when writing to a geomview pipe?

[Lloyd W. <llo...@ya...>]

I'm dealing with the odd situation on linux where
geomview -run savi
works just fine if geomview and savi are installed as
ubuntu packages, but if I compile savi 1.5.1 (matching
the package) SaVi segfaults on first attempting to write to the
pipe to geomview via fprintf.


stdout is set up to point to geomview and dup'd, and there's
a lot of error checking in that code to test for failures
during setup. Those checks pass, but as soon as you fprintf
to the pipe - boom, goodbye your compiled savi.


This code hasn't changed (ie I'm not smart enough to change
it) in years...

Has something changed in stdlib or in how file pointers

can be used and abused in gcc? Ideas to investigate  welcome.

thanks

Lloyd Wood
http://savi.sf.net/

[geomview-users] Antiprism 0.26 Released

[Adrian R. <ad...@an...>]

Hi All

Antiprism 0.26 polyhedron modelling software has been released

      http://www.antiprism.com/download

Windows 32-bit and 64-bit installers and Ubuntu binary packages are
available. Source code is provided for other systems.

The programs all work natively with OFF format. The new release
includes the off2dae program, which allows OFF format models to be
imported into Sketchup.

There is an examples album here

    http://www.antiprism.com/examples/

Adrian.
-- 
Adrian Rossiter
ad...@an...
http://antiprism.com/adrian

[geomview-users] inststream.c:271:35: warning: duplicated 'if' condition [-Wduplicated-cond]

[David B. <dc...@ho...>]

Hello there,

Source code is

    if(inst->tlist != NULL || inst->tlisthandle != NULL) {
        PoolFPrint(pool, outf, "transforms ");
        ok &= GeomStreamOut(pool, inst->tlisthandle, inst->tlist);
    } else if(inst->tlist != NULL || inst->tlisthandle != NULL) {
        PoolFPrint(pool, outf, "txtransforms ");
        ok &= GeomStreamOut(pool, inst->tlisthandle, inst->tlist);

So the txtransforms code can never be executed. Suggest code rework.

Regards

David Binderman

[geomview-users] Geomview used by the European Space Agency

[Lloyd W. <llo...@ya...>]

http://savi.sf.net/papers/index.html#esa



it's rather unexpected, but Geomview (with the SaVi plugin) has been used to render the logo that the European Space Agency (esa) has been using for its megaconstellations project framework for the past couple of years.
 
Lloyd Wood
http://savi.sf.net/

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Stuart L. <sa...@il...>]

The other mystery was why "CC" got set to the g++ compiler rather than
gcc - that messed up several things.

On 08/02/2018 12:10 PM, Michele Denber wrote:
> On 08-01-2018 8:50 PM, Lloyd Wood wrote:
>> Are there any tweaks for portability that can be
>> made to improve Geomview as a result of this experience? I have
>> no idea...
>>
>>
> I really only had two problems - the missing fmemopen in Solaris and
> the whole thing with the socket library functions.  For some reason,
> configure wasn't defining HAVE_UNIX_SOCKETS.  Once those were fixed,
> it compiled just fine.  I don't know if those were one-offs on just my
> system or if they're common to Solaris Sparc in general.
>
>             - Michele
>

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

On 08-01-2018 8:50 PM, Lloyd Wood wrote:
> Are there any tweaks for portability that can be
> made to improve Geomview as a result of this experience? I have
> no idea...
>
>
I really only had two problems - the missing fmemopen in Solaris and the 
whole thing with the socket library functions.  For some reason, 
configure wasn't defining HAVE_UNIX_SOCKETS.  Once those were fixed, it 
compiled just fine.  I don't know if those were one-offs on just my 
system or if they're common to Solaris Sparc in general.

             - Michele

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Lloyd W. <llo...@ya...>]

The manual is available from
http://www.geomview.org/docs/

We moved building the manual to last because it
seemed silly to break a working link and final build just
because everything halted on a TeX problem earlier -
and debugging other people's TeX installs is 
really difficult.

Are there any tweaks for portability that can be
made to improve Geomview as a result of this experience? I have
no idea...

Lloyd Wood
http://savi.sf.net/
the idea companion to a new Geomview install


________________________________
From: Michele Denber <md...@gm...>
To: Stuart Levy <sa...@il...> 
Cc: "geo...@li..." <geo...@li...>; "geo...@li..." <geo...@li...>
Sent: Thursday, 2 August 2018, 2:05
Subject: Re: [geomview-users]  [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared



Well I was getting a slew of errors like:

...
Loading texinfo [version 2013-02-01.11]: pdf, fonts, markup,
      glyphs,
page headings, tables, conditionals, indexing, sectioning, toc,
      environments,
defuns, macros, cross references, insertions, localization,
      formatting,
and turning on texinfo input format.) (./geomview.aux)
(/export/home/denber/geomview-1.9.5/doc/version.texi)
      [1{/opt/csw/share/texmf/f
onts/map/pdftex/updmap/pdftex.map}] (Introduction to Geomview)
      [1]
(Distribution) [2] (Copying) [3] (GNU LESSER PUBLIC LICENSE) [4]
      [5] [6]
[7] [8] [9] [10] [11] [12] (History of Geomview's Development)
      [13]
(Supported Platforms) [14] (How to Pronounce ``Geomview``) [15]
      Chapter 1
[16] Chapter 2 [17]
/export/home/denber/geomview-1.9.5/doc/./geomview.texi:890:
      epsf.tex not found,
 images will be ignored.
@image ...f.tex not found, images will be ignored}
                                                  @global
      @warnednoepsftrue ...
l.890 @image{figs/initial}

[18] [19] Chapter 3 [20] [21]
Underfull \hbox (badness 10000) in paragraph at lines 1189--1192
 @texttt -Mcs fred[]@textrm Read com-mands from the UNIX-domain
      socket named.
...

from gmake but that all looks like a texinfo problem, not
    geomview.  So I just ignored them and did a gmake install anyway. 
    That seems to have created entries in /usr/local/lib and
    /usr/local/bin for geomview so I'm guessing that in the end it
    worked, modulo the documentation (which doesn't matter too much to
    me).

So thank you very much for all your help getting this installed.


            - 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

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

Well I was getting a slew of errors like:

...
Loading texinfo [version 2013-02-01.11]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc, 
environments,
defuns, macros, cross references, insertions, localization, formatting,
and turning on texinfo input format.) (./geomview.aux)
(/export/home/denber/geomview-1.9.5/doc/version.texi) 
[1{/opt/csw/share/texmf/f
onts/map/pdftex/updmap/pdftex.map}] (Introduction to Geomview) [1]
(Distribution) [2] (Copying) [3] (GNU LESSER PUBLIC LICENSE) [4] [5] [6]
[7] [8] [9] [10] [11] [12] (History of Geomview's Development) [13]
(Supported Platforms) [14] (How to Pronounce ``Geomview``) [15] Chapter 1
[16] Chapter 2 [17]
/export/home/denber/geomview-1.9.5/doc/./geomview.texi:890: epsf.tex not 
found,
  images will be ignored.
@image ...f.tex not found, images will be ignored}
                                                   @global 
@warnednoepsftrue ...
l.890 @image{figs/initial}

[18] [19] Chapter 3 [20] [21]
Underfull \hbox (badness 10000) in paragraph at lines 1189--1192
  @texttt -Mcs fred[]@textrm Read com-mands from the UNIX-domain socket 
named.
...

from gmake but that all looks like a texinfo problem, not geomview.  So 
I just ignored them and did a gmake install anyway.  That seems to have 
created entries in /usr/local/lib and /usr/local/bin for geomview so I'm 
guessing that in the end it worked, modulo the documentation (which 
doesn't matter too much to me).

So thank you very much for all your help getting this installed.

             - Michele

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

You were right - there was another c++ file stuck in there.  Doing gmake 
clean fixed that. Then I fixed some more fmemopen problems and finally 
got to the point in the attached gmake log.  I'm not quite sure what 
happened here.  It seems like maybe geomview itself finished but it's 
having trouble making the docs.  In any case, it's gone a lot further 
than before.


             - Michele

Re: [geomview-users] Solaris 10 build fails with link error: undefined symbols in animate

[Stuart L. <sa...@il...>]

Hmm.  Is it possible there could be some old .o files, compiled with g++ (from before you changed the setting of CC) instead of gcc ?   I'm puzzled at the set of C++-style mangled names among the undefined symbols, which shouldn't be there if only a plain C compiler has been involved.   Wonder if you can get rid of old .o files (maybe typing 'make clean' could do) and build again?
 


 -- Stuart
-------- Original message --------From: Michele Denber <md...@gm...> Date: 7/29/18  19:34  (GMT-06:00) To: Stuart Levy <sa...@il...>, geo...@li..., geo...@li... Subject: Solaris 10 build fails with link error: undefined symbols in animate 

    I think I'm close to getting this build done.  Now I have a linking
    error:

    

    ...

        /bin/bash ../../../libtool  --tag=CC   --mode=link gcc  -g -O2 
        -lsocket -o animate animate.o xanimate.o glob.o
        ../../../src/lib/mib/libmib.a -lXm -lXmu -L/usr/openwin/lib
        -R/usr/openwin/lib  -lSM -lICE -lXt -lXext -lX11  -lnsl -lm

        libtool: link: gcc -g -O2 -o animate animate.o xanimate.o
        glob.o  -lsocket ../../../src/lib/mib/libmib.a -lXm -lXmu
        -L/usr/openwin/lib -lSM -lICE -lXt -lXext -lX11 -lnsl -lm
        -R/usr/openwin/lib

        Undefined                       first referenced

         symbol                             in file

        anim_play                           xanimate.o

        anim_once                           xanimate.o

        anim_load                           xanimate.o

        anim_stop                           xanimate.o

        anim_playing                        xanimate.o

        _Z10UIstopplayv                     animate.o

        anim_close                          xanimate.o

        anim_stepb                          xanimate.o

        anim_stepf                          xanimate.o

        anim_range                          xanimate.o

        _Z15UIloadinterfacev                animate.o

        anim_bounce                         xanimate.o

        _Z10UIsetframePc                    animate.o

        _Z9UIsetOncei                       animate.o

        _Z15UIshowinterfacev                animate.o

        _Z9UIaddlistPc                      animate.o

        anim_setcommand                     xanimate.o

        _Z13UIgetselectedPPiS_              animate.o

        _Z4globPc                           animate.o

        anim_loadscript                     xanimate.o

        _Z10UImainloopv                     animate.o

        get_info                            xanimate.o

        anim_goframe                        xanimate.o

        _Z10UIsetSpeedi                     animate.o

        _Z11UIclearlistv                    animate.o

        _Z11UIstartplayv                    animate.o

        _Z11UIsetBouncei                    animate.o

        ld: fatal: symbol referencing errors. No output written to
        animate

        gmake[5]: *** [Makefile:525: animate] Error 1

      

    I don't know how to fix this one.

    

                - Michele

    

  

[geomview-users] Solaris 10 build fails with link error: undefined symbols in animate

[Michele D. <md...@gm...>]

I think I'm close to getting this build done.  Now I have a linking error:

...
/bin/bash ../../../libtool  --tag=CC   --mode=link gcc  -g -O2  -lsocket 
-o animate animate.o xanimate.o glob.o ../../../src/lib/mib/libmib.a 
-lXm -lXmu -L/usr/openwin/lib -R/usr/openwin/lib  -lSM -lICE -lXt -lXext 
-lX11  -lnsl -lm
libtool: link: gcc -g -O2 -o animate animate.o xanimate.o glob.o  
-lsocket ../../../src/lib/mib/libmib.a -lXm -lXmu -L/usr/openwin/lib 
-lSM -lICE -lXt -lXext -lX11 -lnsl -lm -R/usr/openwin/lib
Undefined                       first referenced
  symbol                             in file
anim_play                           xanimate.o
anim_once                           xanimate.o
anim_load                           xanimate.o
anim_stop                           xanimate.o
anim_playing                        xanimate.o
_Z10UIstopplayv                     animate.o
anim_close                          xanimate.o
anim_stepb                          xanimate.o
anim_stepf                          xanimate.o
anim_range                          xanimate.o
_Z15UIloadinterfacev                animate.o
anim_bounce                         xanimate.o
_Z10UIsetframePc                    animate.o
_Z9UIsetOncei                       animate.o
_Z15UIshowinterfacev                animate.o
_Z9UIaddlistPc                      animate.o
anim_setcommand                     xanimate.o
_Z13UIgetselectedPPiS_              animate.o
_Z4globPc                           animate.o
anim_loadscript                     xanimate.o
_Z10UImainloopv                     animate.o
get_info                            xanimate.o
anim_goframe                        xanimate.o
_Z10UIsetSpeedi                     animate.o
_Z11UIclearlistv                    animate.o
_Z11UIstartplayv                    animate.o
_Z11UIsetBouncei                    animate.o
ld: fatal: symbol referencing errors. No output written to animate
gmake[5]: *** [Makefile:525: animate] Error 1

I don't know how to fix this one.

             - Michele

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

Turns out there was almost a dozen other files that wanted the fmemopen 
fix so I put that code in all of them too and pushed on ahead.  Now I'm 
stuck here:

Making all in animate
gmake[4]: Entering directory 
'/export/home/denber/geomview-1.9.5/src/bin/animate'
Making all in interface
gmake[5]: Entering directory 
'/export/home/denber/geomview-1.9.5/src/bin/animate/interface'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory 
'/export/home/denber/geomview-1.9.5/src/bin/animate/interface'
gmake[5]: Entering directory 
'/export/home/denber/geomview-1.9.5/src/bin/animate'
gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include     -g -O2 -MT 
xanimate.o -MD -MP -MF .deps/xanimate.Tpo -c -o xanimate.o xanimate.c
mv -f .deps/xanimate.Tpo .deps/xanimate.Po
gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include     -g -O2 -MT 
glob.o -MD -MP -MF .deps/glob.Tpo -c -o glob.o glob.c
mv -f .deps/glob.Tpo .deps/glob.Po
/bin/bash ../../../libtool  --tag=CC   --mode=link gcc  -g -O2  -lsocket 
-o animate animate.o xanimate.o glob.o ../../../src/lib/mib/libmib.a 
-lXm -lXmu -L/usr/openwin/lib -R/usr/openwin/lib  -lSM -lICE -lXt -lXext 
-lX11  -lnsl -lm
libtool: link: gcc -g -O2 -o animate animate.o xanimate.o glob.o  
-lsocket ../../../src/lib/mib/libmib.a -lXm -lXmu -L/usr/openwin/lib 
-lSM -lICE -lXt -lXext -lX11 -lnsl -lm -R/usr/openwin/lib
Undefined                       first referenced
  symbol                             in file
anim_play                           xanimate.o
anim_once                           xanimate.o
anim_load                           xanimate.o
anim_stop                           xanimate.o
anim_playing                        xanimate.o
_Z10UIstopplayv                     animate.o
anim_close                          xanimate.o
anim_stepb                          xanimate.o
anim_stepf                          xanimate.o
anim_range                          xanimate.o
_Z15UIloadinterfacev                animate.o
anim_bounce                         xanimate.o
_Z10UIsetframePc                    animate.o
_Z9UIsetOncei                       animate.o
_Z15UIshowinterfacev                animate.o
_Z9UIaddlistPc                      animate.o
anim_setcommand                     xanimate.o
_Z13UIgetselectedPPiS_              animate.o
_Z4globPc                           animate.o
anim_loadscript                     xanimate.o
_Z10UImainloopv                     animate.o
get_info                            xanimate.o
anim_goframe                        xanimate.o
_Z10UIsetSpeedi                     animate.o
_Z11UIclearlistv                    animate.o
_Z11UIstartplayv                    animate.o
_Z11UIsetBouncei                    animate.o
ld: fatal: symbol referencing errors. No output written to animate
gmake[5]: *** [Makefile:525: animate] Error 1

             - Michele

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

On 07/27/18 17:41, Stuart Levy wrote:
> ...
>
> In case you get a warning about a conflicting definition of fmemopen 
> in comm.h, that may mean that Solaris header files declare their own 
> fmemopen, even though their libraries don't contain it.   If so, then 
> you might need to change the above definition of fmemopen() to 
> whatever the Solaris headers say -- for example they might mention 
> "char *buf" rather than "void *buf".
Yes, that's about what I got:

In file included from comm.c:66:0:
comm.h:45:7: error: conflicting types for ‘fmemopen’
  FILE *fmemopen(const void *buf, size_t size, const char *mode);
        ^
In file included from ../../../../include/ooglutil.h:323:0,
                  from comm.c:58:
../../../../include/porting.h:96:14: note: previous declaration of 
‘fmemopen’ was here
  extern FILE *fmemopen(void *buf, size_t buflen, char *mode);
               ^
comm.c:89:7: error: conflicting types for ‘fmemopen’
  FILE *fmemopen(void *buf, size_t size, const char *mode)
        ^
In file included from ../../../../include/ooglutil.h:323:0,
                  from comm.c:58:
../../../../include/porting.h:96:14: note: previous declaration of 
‘fmemopen’ was here
  extern FILE *fmemopen(void *buf, size_t buflen, char *mode);
               ^
gmake[5]: *** [Makefile:435: comm.o] Error 1

So I changed both comm.c and comm.h to be:

FILE *fmemopen(void *buf, size_t size,  char *mode);

and got past that error.  Now we're stopping with

Making all in togeomview
gmake[4]: Entering directory 
'/export/home/denber/geomview-1.9.5/src/bin/togeomview'
/bin/bash ../../../libtool  --tag=CC   --mode=link gcc  -g -O2  -lsocket 
-o togeomview togeomview.o  -lm
libtool: link: gcc -g -O2 -o togeomview togeomview.o  -lsocket -lm
Undefined                       first referenced
  symbol                             in file
gethostbyname                       togeomview.o  (symbol belongs to 
implicit dependency /lib/libnsl.so.1)
ld: fatal: symbol referencing errors. No output written to togeomview
gmake[4]: *** [Makefile:472: togeomview] Error 1

I tried changing

  LDFLAGS=-lsocket

to

  LDFLAGS="-lsocket -lnsl"

but that didn't help.  This is progress but I'm afraid I'm stuck again.

             - Michele

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Stuart L. <sa...@il...>]

It looks as though yes, solaris really doesn't have fmemopen.

Here's a stub function which may work to replace fmemopen, for the
limited uses that geomview makes of it.   It looks as though Solaris
header files *do* declare it - otherwise you'd have gotten a compilation
error, right?   Could you try (a) inserting the following somewhere near
the top of .../src/bin/geomview/common/comm.c, and (b) re-making?   If
that fails try (c) below too.

(a) add somewhere in .../src/bin/geomview/common/comm.h  :

FILE *fmemopen(const void *buf, size_t size, const char *mode);

(b) add somewhere in .../src/bin/geomview/common/comm.c :


#include <stdio.h>
#include <unistd.h>


FILE *fmemopen(void *buf, size_t size, const char *mode)
{
    int pipefds[2];

    if(size > 4096) {
        /* avoid deadlock - we might be unable to write a long string to
a pipe */
        fprintf(stderr, "fmemopen: can only work from buffers <= 4K
long, not %ld\n", (long)size);
        return NULL;
    }
    if(mode[0] != 'r') {
        fprintf(stderr, "fmemopen: can only read, not write\n");
        return NULL;
    }

    if(pipe( pipefds ) < 0) {
        perror("fmemopen: can't make pipe");
        return NULL;
    }

    /* pipefds[1] is the writing end of the pipe.  Write data and close
it. */
    if(write( pipefds[1], buf, size ) < size) {
        perror("fmemopen: trouble writing to pipe");
    }
    close(pipefds[1]);

    return fdopen( pipefds[0], mode );
}

====
and finally (c) re-run "make", and see what happens.

In case you get a warning about a conflicting definition of fmemopen in
comm.h, that may mean that Solaris header files declare their own
fmemopen, even though their libraries don't contain it.   If so, then
you might need to change the above definition of fmemopen() to whatever
the Solaris headers say -- for example they might mention "char *buf"
rather than "void *buf".

Alternatively, you could rename all the  fmemopen()'s to something else
(like "my_fmemopen(...)") and likewise change the Geomview references to
fmemopen() in comm.c, drawer.c, lights.c -- the places reported by the
errors you mention.

Sorry for the trouble.

   Stuart


On 07/27/2018 02:54 PM, Michele Denber wrote:
> OK, well I figured out the primary problem.  For some reason all the
> Makefiles had CC=g++ in them.  I changed them all to CC=gcc and got
> everything to compile.  (How do I get configure to know that CC should
> be gcc and not g++ in the first place?)
>
> But now we have a new missing link: fmemopen:
>
> ...
> gmake[6]: Entering directory
> '/export/home/denber/geomview-1.9.5/src/bin/geomview/x11'
> /bin/bash ../../../../libtool  --tag=CC   --mode=link gcc  -g -O2 
> -lsocket -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 -lsocket -lGL -lGLU -lz -lSM -lICE -lXt -lXext -lX11
> -lnsl -lm -R/usr/local/lib -R/usr/openwin/lib
> /opt/csw/bin/gld: warning: libm.so.1, needed by
> /usr/openwin/lib/libGL.so, may conflict with libm.so.2
> ../common/libgvcommon.a(comm.o): In function `comm_object':
> /export/home/denber/geomview-1.9.5/src/bin/geomview/common/comm.c:256:
> undefined reference to `fmemopen'
> ../common/libgvcommon.a(drawer.o): In function `drawer_init':
> /export/home/denber/geomview-1.9.5/src/bin/geomview/common/drawer.c:2330:
> undefined reference to `fmemopen'
> /export/home/denber/geomview-1.9.5/src/bin/geomview/common/drawer.c:2438:
> undefined reference to `fmemopen'
> ../common/libgvcommon.a(lights.o): In function `clight_init':
> /export/home/denber/geomview-1.9.5/src/bin/geomview/common/lights.c:104:
> undefined reference to `fmemopen'
> gmake[6]: *** [Makefile:494: gvx] Error 1
> gmake[6]: Leaving directory
> '/export/home/denber/geomview-1.9.5/src/bin/geomview/x11'
> gmake[5]: *** [Makefile:553: all-recursive] Error 1
> gmake[5]: Leaving directory
> '/export/home/denber/geomview-1.9.5/src/bin/geomview/x11'
> gmake[4]: *** [Makefile:483: all-recursive] Error 1
> gmake[4]: Leaving directory
> '/export/home/denber/geomview-1.9.5/src/bin/geomview'
> gmake[3]: *** [Makefile:406: all-recursive] Error 1
> gmake[3]: Leaving directory '/export/home/denber/geomview-1.9.5/src/bin'
> gmake[2]: *** [Makefile:473: all-recursive] Error 1
> gmake[2]: Leaving directory '/export/home/denber/geomview-1.9.5/src'
> gmake[1]: *** [Makefile:540: all-recursive] Error 1
> gmake[1]: Leaving directory '/export/home/denber/geomview-1.9.5'
> gmake: *** [Makefile:429: all] Error 2
> #
>
> From what I gather, Solaris doesn't have this.  ??
>
>             - Michele
>
>
>

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

OK, well I figured out the primary problem.  For some reason all the 
Makefiles had CC=g++ in them.  I changed them all to CC=gcc and got 
everything to compile.  (How do I get configure to know that CC should 
be gcc and not g++ in the first place?)

But now we have a new missing link: fmemopen:

...
gmake[6]: Entering directory 
'/export/home/denber/geomview-1.9.5/src/bin/geomview/x11'
/bin/bash ../../../../libtool  --tag=CC   --mode=link gcc  -g -O2  
-lsocket -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 -lsocket -lGL -lGLU -lz -lSM -lICE -lXt -lXext -lX11 
-lnsl -lm -R/usr/local/lib -R/usr/openwin/lib
/opt/csw/bin/gld: warning: libm.so.1, needed by 
/usr/openwin/lib/libGL.so, may conflict with libm.so.2
../common/libgvcommon.a(comm.o): In function `comm_object':
/export/home/denber/geomview-1.9.5/src/bin/geomview/common/comm.c:256: 
undefined reference to `fmemopen'
../common/libgvcommon.a(drawer.o): In function `drawer_init':
/export/home/denber/geomview-1.9.5/src/bin/geomview/common/drawer.c:2330: undefined 
reference to `fmemopen'
/export/home/denber/geomview-1.9.5/src/bin/geomview/common/drawer.c:2438: undefined 
reference to `fmemopen'
../common/libgvcommon.a(lights.o): In function `clight_init':
/export/home/denber/geomview-1.9.5/src/bin/geomview/common/lights.c:104: 
undefined reference to `fmemopen'
gmake[6]: *** [Makefile:494: gvx] Error 1
gmake[6]: Leaving directory 
'/export/home/denber/geomview-1.9.5/src/bin/geomview/x11'
gmake[5]: *** [Makefile:553: all-recursive] Error 1
gmake[5]: Leaving directory 
'/export/home/denber/geomview-1.9.5/src/bin/geomview/x11'
gmake[4]: *** [Makefile:483: all-recursive] Error 1
gmake[4]: Leaving directory 
'/export/home/denber/geomview-1.9.5/src/bin/geomview'
gmake[3]: *** [Makefile:406: all-recursive] Error 1
gmake[3]: Leaving directory '/export/home/denber/geomview-1.9.5/src/bin'
gmake[2]: *** [Makefile:473: all-recursive] Error 1
gmake[2]: Leaving directory '/export/home/denber/geomview-1.9.5/src'
gmake[1]: *** [Makefile:540: all-recursive] Error 1
gmake[1]: Leaving directory '/export/home/denber/geomview-1.9.5'
gmake: *** [Makefile:429: all] Error 2
#

 From what I gather, Solaris doesn't have this.  ??

             - Michele

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

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

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Stuart L. <sa...@il...>]

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

Re: [geomview-users] Fwd: Re: Fwd: Re: Fwd: Re: [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

>
>
>
>
>
>
> 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

Re: [geomview-users] Fwd: Re: Fwd: Re: [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[<llo...@ya...>]

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

Re: [geomview-users] Fwd: Re: Fwd: Re: [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

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