[ksh93-integration-discuss] Re: [ast-users] /dev/tcp+/dev/udp notcompiled-in for Solaris ksh93r...

[Glenn Fowler]

this is way beyond the scope the ksh93 integration and it
would require different components of the C compilation system to cooperate
but it is possible to let/force the system headers assert the required
link time libraries

for example,

	#pragma link_with -lsocket -lnsl

in <sys/socket.h>, passed down to the linker, would solve most makefile
link time problems

that is, each system header that presents an interface not in libc
provides a #pragma that pulls in the correct libraries

further, the #pragma's could be conditioned by the standard in scope

	#if _XPG_BOO_FAR_SOURCE
	#pragma link_with -lxnet
	#else
	#pragma link_with -lsocket -lnsl
	#endif

configure/iffe scripts that check for required libraries would
basically determine that no extra -l* libs would be required for
the <sys/*.h> apis -- essentially, all system header apis would
appear to be provided in the default libraries

about "-lsocket -lnsl" vs. portable cm (solaris + everyone else)
going into the weeds for "-lsocket -lnsl" *for solaris* may be fine
but determining "-lsocket -lnsl" for other systems may not be so simple
there is at least one system where "-lsocket -lnsl" is the wrong choice
and I'm sure there are other systems with magic -l* sequences I don't
know about required to get the <sys/socket.h> api to work
i.e., when just considering solaris, "-lsocket -lnsl" doesn't seem so bad
but if other systems took the same liberties with <sys/foo.h> it would
be a big arbitrary mess (as if portability weren't that already)

-- Glenn Fowler -- AT&T Research, Florham Park NJ --

On Fri, 8 Sep 2006 08:46:11 -0400 James Carlson wrote:
> Backing up a bit, what I was pointing out here wasn't that folding
> libxnet functionality in was in any way trivial, but rather that we
> need to be very careful in what we decide to bring over to libc,
> regardless of how upset we might be at the present annoyance of
> -lsocket -lnsl.  Once we bring it in, there's no going back.

> With that in mind, I'd much rather see the richer standards-conformant
> environment become the default, and have applications that need to
> wander off into the weeds by specifying "-lsocket -lnsl" do so
> explicitly.  Using -lsocket as the default, no matter how common it
> might seem, looks like a big step backwards to me.

> The sticky parts are the #ifdef'd goop in the header files, not the
> libraries themselves.  It's non-trivial, but I suspect that it could
> be pulled off if we're willing to accept some corner cases that result
> in source incompatibility.