[netperf-talk] netperf4: solaris building, and usage..

[Rick Jones]

Andrew Gallatin wrote:
> Rick Jones writes:
> 
>  > > 2) Somewhere in here, the build dies because it cannot find
>  > > netsysstats_kstat10.c and netlib_kstat10.c.   This confused
>  > > me, since configure knows about them.  Do they exist, just
>  > > not on this branch?  Anyway, I copied the _none variants
>  > > over to their names.
>  > 
>  > That is the correct first step.  That will give files with "null" CPU 
>  > util and processor affinity calls.
> 
> OK.  I did some archive reading over the weekend.  Apparently
> this came up before.  If I can get netperf4 working, I'll
> re-implement the kstat util stuff.
> 
>  > > 2) At this point, the build dies complaining about passing a
>  > > GNUish --export-dynamic dynamic to ld.  I edited src/Makefile
>  > > by hand and removed this flag.
>  > 
>  > Libtool bug perhaps, or was there an actual --export-dynamic in one of 
>  > the ".am" makefiles?
> 
> % grep export-dynamic src/Makefile.am 
> netperf_LDFLAGS = -rpath $(libdir) -export-dynamic

Hmmm, I thought that was a libtoolism that would be "translated" as 
required by the libtool stuff.

> Interestingly, I removed it from the .am file, and
> the build still puked the same way.  These GNUish auto*
> things confuse the heck out of me.  Do I need to rerun some
> auto* thingie?

Yes, the stuff in autogen.sh will convert the .am's to .in's, and then 
configure converts the .in's to proper makefiles.

> In the same spirit, the build seems to want to tack the
> -pthread linux-ism onto the gcc compiler commandline.  I'm not
> sure where this is coming from, but it at least just
> generates a warning.

That comes from stuff in configure that ass-u-me-s that if the compiler 
is gcc that one wants to use -pthread.  The reason it is doing stuff 
like that is that pkg-config will give options from the compiler used to 
compile the dependency, not necessarily the compiler being used to 
compile netperf4.  So, netperf4 has to use the "only" options to 
pkg-config and then "guess" others to add-back-in.

> Speaking of configure.  It takes about 6 minutes to
> run configure on a T2000.  It seems to want to figure out
> all sorts of stuff you don't care about (like testing for
> fortran and c++ compilers).   Can that be eliminated somehow?

Those come from the use of libtool.  As for taking 6 minutes, I can only 
suggest your T2000 is slow :)

>  > Hmm, seems that solaris dumps core where others might not.  You can use 
>  > the -L option to specify the local control endpoint stuff.  As a start 
>  > you can try -L localhost  so  src/netserver -L localhost
>  > 
>  > Make sure that "netperf4" is in /etc/services or whatever your system 
>  > uses to lookup service names.
> 
> Ick.  That means you need to be root to install and use netperf.

Install yes.  Use, no.  Netperf _should_ not require the /etc/services 
stuff, but that hasn't been done yet.  A fertile area for patching :)

> 
>  > Also make sure that /etc/xml/catalog got updated during the make install 
>  > to include an entry for netperf.
> 
> That was it.  The xml code stops SEGV'ing when you do this.
> 
> But that means you need to be root to use netperf.  That totally kills
> portability of binaries to systems you don't own, and greatly reduces
> netperf's value as a diagnostic tool.

That would be only to install - once the entry is in /etc/xml/catalog 
all should be well even for a mortal userid.

There are in theory env vars one can use to point the XML code at a 
catalog elsewhere where a mere mortal might be able to edit it.  I 
_think_ it might be XML_CATALOG_FILES.

> Is there any way to remove the xml requirement (possibly via
> a configure option) and go back to the nice, simple, easy to
> use command line arguments like netperf2.x has?

Nope.  Use of XML is deeply embedded into netperf4's psyche.

rick