[GRASS5] XEXTRALIBS and -lsocket

GRASS GRASS developer
1

Hi all,

while compiling GRASS on Solaris I have found that XEXTRALIBS
would be required in various Gmakefiles (as posted before by others).
What to do now:
- add XEXTRALIBS in mayn Gmakefile (all d.*, many others)
- use another trick to get XEXTRALIBS in use?

Note: The head file contains:

Linux: XEXTRALIBS =
        
Solaris: XEXTRALIBS = -lsocket -lnsl

          -lnsl is present in XDRLIB as well on Solaris.

I will do the change, but need a recommendation.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Hi Markus

Markus Neteler wrote:

Note: The head file contains:

Linux: XEXTRALIBS =

Solaris: XEXTRALIBS = -lsocket -lnsl

          -lnsl is present in XDRLIB as well on Solaris.

Why is -lsocket (and -lnsl for that matter) defined for the XEXTRALIBS
make variable? Sockets have nothing to do with the X window system. I
would suggest to create another make variable for sockets. Mixing
libraries with inappropriate make variables is only confusing. We should
be trying to minimize confusion, not adding to it.

Just my 2 cents worth.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

On Wed, Mar 07, 2001 at 04:08:16PM +0700, Justin Hickey wrote:

Hi Markus

Markus Neteler wrote:
> Note: The head file contains:
>
> Linux: XEXTRALIBS =
>
> Solaris: XEXTRALIBS = -lsocket -lnsl
>
> -lnsl is present in XDRLIB as well on Solaris.

Why is -lsocket (and -lnsl for that matter) defined for the XEXTRALIBS
make variable? Sockets have nothing to do with the X window system. I
would suggest to create another make variable for sockets. Mixing
libraries with inappropriate make variables is only confusing. We should
be trying to minimize confusion, not adding to it.

Accepted! But this is done by "configure"... not my idea.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Wed, Mar 07, 2001 at 10:08:11AM +0000, Markus Neteler wrote:

On Wed, Mar 07, 2001 at 04:08:16PM +0700, Justin Hickey wrote:
> Hi Markus
>
> Markus Neteler wrote:
> > Note: The head file contains:
> >
> > Linux: XEXTRALIBS =
> >
> > Solaris: XEXTRALIBS = -lsocket -lnsl
> >
> > -lnsl is present in XDRLIB as well on Solaris.
>
> Why is -lsocket (and -lnsl for that matter) defined for the XEXTRALIBS
> make variable? Sockets have nothing to do with the X window system. I
> would suggest to create another make variable for sockets. Mixing
> libraries with inappropriate make variables is only confusing. We should
> be trying to minimize confusion, not adding to it.
Accepted! But this is done by "configure"... not my idea.

an addition:
It seems to result from the "gethostname" test in configure[.in]

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

.. one more:

http://www.amath.washington.edu/~lf/tutorials/autoconf/autoconf/autoconf.html#SEC21

Macro: AC_PATH_XTRA

    An enhanced version of AC_PATH_X. It adds the C compiler flags that X
    needs to output variable X_CFLAGS, and the X linker
    flags to X_LIBS. If X is not available, adds '-DX_DISPLAY_MISSING' to
    X_CFLAGS.

    This macro also checks for special libraries that some systems need in
    order to compile X programs. It adds any that the system
    needs to output variable X_EXTRA_LIBS. And it checks for special X11R6
    libraries that need to be linked with before
    '-lX11', and adds any found to the output variable X_PRE_LIBS.

It seems to be related to X_EXTRA_LIBS or not?

Yours
Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

Hi Markus

Markus Neteler wrote:

Macro: AC_PATH_XTRA

    An enhanced version of AC_PATH_X. It adds the C compiler flags
    that X needs to output variable X_CFLAGS, and the X linker
    flags to X_LIBS. If X is not available, adds'-DX_DISPLAY_MISSING'
    to X_CFLAGS.

    This macro also checks for special libraries that some systems
    need in order to compile X programs. It adds any that the system
    needs to output variable X_EXTRA_LIBS. And it checks for special
    X11R6 libraries that need to be linked with before
    '-lX11', and adds any found to the output variable X_PRE_LIBS.

It seems to be related to X_EXTRA_LIBS or not?

Hmmm. This is interesting. This means that on Solaris, X_EXTRA_LIBS has
always been defined as -lsocket -lnsl. Now, the d.* commands are not
linking with the new socket code, which means that they require a
-lsocket to link. The question is do we use the X_EXTRA_LIBS variable to
add this to the d.* commands? I would say no since the d.* commands
didn't need the X_EXTRA_LIBS before the socket code. Thus, I still
recommend that we create a new make variable for -lsocket. Anyway,
that's just my opinion.

However, I just saw you added it to XDRLIB.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

Hi again,

here a proposal: An easy way to fix the -lsocket problem is
to modify
src/CMD/head/head.in

XDRLIB = @XDRLIB@ @ZLIBINCPATH@ @ZLIBLIBPATH@ @ZLIB@ $(XEXTRALIBS)

This works for Linux (XEXTRALIBS is empty there) and fixes the
Solaris problems.

I modify in CVS. If anything breaks (I don't know how), we
can search for another solution.

Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

Hi Markus

XDRLIB = @XDRLIB@ @ZLIBINCPATH@ @ZLIBLIBPATH@ @ZLIB@ $(XEXTRALIBS)

This is what I mean by confusing. I have added a comment to the TODO.txt
file to clean up the make variables.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

On Wed, Mar 07, 2001 at 05:13:25PM +0700, Justin Hickey wrote:

Hi Markus

Markus Neteler wrote:
> Macro: AC_PATH_XTRA
>
> An enhanced version of AC_PATH_X. It adds the C compiler flags
> that X needs to output variable X_CFLAGS, and the X linker
> flags to X_LIBS. If X is not available, adds'-DX_DISPLAY_MISSING'
> to X_CFLAGS.
>
> This macro also checks for special libraries that some systems
> need in order to compile X programs. It adds any that the system
> needs to output variable X_EXTRA_LIBS. And it checks for special
> X11R6 libraries that need to be linked with before
> '-lX11', and adds any found to the output variable X_PRE_LIBS.
>
> It seems to be related to X_EXTRA_LIBS or not?

Hmmm. This is interesting. This means that on Solaris, X_EXTRA_LIBS has
always been defined as -lsocket -lnsl. Now, the d.* commands are not
linking with the new socket code, which means that they require a
-lsocket to link. The question is do we use the X_EXTRA_LIBS variable to
add this to the d.* commands? I would say no since the d.* commands
didn't need the X_EXTRA_LIBS before the socket code. Thus, I still
recommend that we create a new make variable for -lsocket. Anyway,
that's just my opinion.

However, I just saw you added it to XDRLIB.

Please consider this as interim solution. If you have an idea to
separate the -lsocket, we should clean up. I just wanted to
get GRASS immediately compilable on Solaris.

Yours

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

On Wed, Mar 07, 2001 at 05:21:23PM +0700, Justin Hickey wrote:

Hi Markus

> XDRLIB = @XDRLIB@ @ZLIBINCPATH@ @ZLIBLIBPATH@ @ZLIB@ $(XEXTRALIBS)

This is what I mean by confusing.

I agree :slight_smile:

I have added a comment to the TODO.txt
file to clean up the make variables.

I agree as well - a task for the new Makefile system.

BTW: Shall we tag the release branch (or whatever it is calles now) today
from src/CMD/lists/GRASS ? Weather is nice, so we could start to
release the GRASS stable...

Yours

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

Hi Markus

Sorry for acting like a stick in the mud concerning the -lsocket thing.
It's just that these types of "quick fixes" exist throughout the grass
code and they only lead to frustration for me when I try to figure out
what is going on. I completely understand why these are done (they
usually save a ton of time) but I automatically suggest other solutions
when I see one being proposed. In this case, the new Makefile system is
the best place to fix it.

Markus Neteler wrote:

BTW: Shall we tag the release branch (or whatever it is calles now)
today from src/CMD/lists/GRASS ? Weather is nice, so we could start
to release the GRASS stable...

The only issue left is cleaning out the fifo and ipc code. However, this
can wait until after the release (BTW, I recommend we either clean it
before the release or clean the MAIN branch after the release branch is
created - safest way I think). The only problem I can remember that was
not solved for the socket code was changing the binaryInstall.src code
(and a bug report on RT from yesterday). This can be handled by everyone
agreeing that nobody will make a binary installation based on fifos or
ipc. Then we just comment out the few lines in the binaryInstall script
that create the fifos. If necessary, if a system cannot compile the
socket version, then whoever creates the binaries can uncomment the fifo
code in their local version of binaryInstall.

So, I see no problem with creating a release branch.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

On Wed, Mar 07, 2001 at 05:52:50PM +0700, Justin Hickey wrote:

Hi Markus

Sorry for acting like a stick in the mud concerning the -lsocket thing.

no problem!

It's just that these types of "quick fixes" exist throughout the grass
code and they only lead to frustration for me when I try to figure out
what is going on. I completely understand why these are done (they
usually save a ton of time) but I automatically suggest other solutions
when I see one being proposed. In this case, the new Makefile system is
the best place to fix it.

Still I agree, to add inconsistencies is not a good idea. Maybe we can
make this exception as all the Makefile stuff is subject to change
soon.

BTW: GRASS/CVS now compiles on SUN/Solaris *without* any compile error :slight_smile:

Markus Neteler wrote:
> BTW: Shall we tag the release branch (or whatever it is calles now)
> today from src/CMD/lists/GRASS ? Weather is nice, so we could start
> to release the GRASS stable...

The only issue left is cleaning out the fifo and ipc code.

Up to now we have no real reason to keep fifo and/or ipc code.
Bernhard didn't denote yet a platform which doesn't support sockets.

As CVS will keep the fifo/ipc code for us, I propose to remove both from
GRASS.

However, this
can wait until after the release (BTW, I recommend we either clean it
before the release or clean the MAIN branch after the release branch is
created - safest way I think). The only problem I can remember that was
not solved for the socket code was changing the binaryInstall.src code
(and a bug report on RT from yesterday). This can be handled by everyone
agreeing that nobody will make a binary installation based on fifos or
ipc. Then we just comment out the few lines in the binaryInstall script
that create the fifos. If necessary, if a system cannot compile the
socket version, then whoever creates the binaries can uncomment the fifo
code in their local version of binaryInstall.

Sounds good to me!

So, I see no problem with creating a release branch.

Fine. Anyone else?

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

13

On Wed, Mar 07, 2001 at 12:59:07PM +0000, Markus Neteler wrote:

On Wed, Mar 07, 2001 at 05:52:50PM +0700, Justin Hickey wrote:
> Hi Markus
>
> Sorry for acting like a stick in the mud concerning the -lsocket thing.
no problem!

[snip...]

Still I agree, to add inconsistencies is not a good idea. Maybe we can
make this exception as all the Makefile stuff is subject to change
soon.

Yea, will need a short-term fix for GRASS 5.0. I expect a ground up
rewrite of the build system for 5.1, or do I misunderstand something?

It makes sense that the X macros catch the linker flags, since X does
have a bit of networking code :wink:

BTW: GRASS/CVS now compiles on SUN/Solaris *without* any compile error :slight_smile:

> Markus Neteler wrote:
> > BTW: Shall we tag the release branch (or whatever it is calles now)
> > today from src/CMD/lists/GRASS ? Weather is nice, so we could start
> > to release the GRASS stable...
>
> The only issue left is cleaning out the fifo and ipc code.

And outstanding bugs...

> So, I see no problem with creating a release branch.
Fine. Anyone else?

I'm working on some more d.area fixes (Note: I introduced a subtle bug
last night by accident...); Also, need to do some work on d.mon --
sometimes (especially with CELL driver) the selection code of d.mon
doesn't succeed. Running d.mon select=DRIVER will work. There's a
timing issue with how long it takes the CELL/PNG/HTMLMAP driver to start
up -- hence d.mon is trying to test the connection before the driver is
ready. There are also, the various other RT bugs...

Apologize that it takes a long time for me to comment. My ISP is
suffering brain damage and mails are being delayed by as much as 24
hours...

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

14

Hi Eric

"Eric G. Miller" wrote:

> > The only issue left is cleaning out the fifo and ipc code.

And outstanding bugs...

The plan was to create the release branch and then work on the
outstanding bugs. This way if somebody checks a new feature into the
MAIN branch, it won't effect the release code. Trying to wait until all
outstanding bugs are fixed doesn't work since new featured can cause
more bugs as we have seen in the past (beta 11). So, we are not
forgetting about the bugs, we just create the branch with the
understanding that bugs will need to be fixed. Does this make sense.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'