🚀 go-pugleaf

>>> Fred Ma wrote:

(Pre-disclaimer to anything I said in this message: I've no experience to deal
with compiling & linking on Sparc, but only on x86 unixes (*BSD, Linuxes).
Something from my words can be non-portable to your system, if it is on Sparc.)

FM> I'm converting a C++ program into a function that can be
FM> called by an external application.  Specifically, I will be
FM> invoking it from a scientific computation package called
FM> Matlab.  It needs my program (main converted into an
FM> actual function) to be compiled with the "gcc -shared"
FM> option, which creates position-indepedent code.

No, -shared doesn't produce position-independent code by itself.
Info gcc specifies this explicitly:

==={{{
`-shared'
     Produce a shared object which can then be linked with other
     objects to form an executable.  Not all systems support this
     option.  You must also specify `-fpic' or `-fPIC' on some systems
     when you specify this option.
===}}}

Word "must" in this citation is too strong: nothing (at least on x86,
but I think it's true for Sparc also) prevents you from building
shared library without PIC. But this isn't recommended way (see below).

FM> My question is:  is execution speed or optimizability
FM> (gcc -O) affected by -shared?  I'm not too sure how to
FM> compare shared vs. nonshared.

`shared' affects execution time in the only way: it requires additional
time for dynamic linker to load library, parse its export and import
list, resolve unresolved links in this list. This time is spent once
on any program startup. It is usually too small, but can be very huge.
E.g., mozilla-1.0 loads on my at-work Linux box (Intel CC820, Celeron 900)
for 8 seconds, and 7.5 seconds of them are dedicated to load dynamic
libraries and resolve cross links. (There are special options in new
binutils which compresses cross-link lists for faster parsing,
`-fcombreloc' for ld; this wasn't applied yet to this mozilla package.)

Position-independent code has one big advantage: it makes code of shared
library minimally touched (usually only a few pages) in any process.
In system with unified virtual memory (as most modern Unixes are), this means
that any process with this library will have most of data of the library
shared in one real instance between all processes which loaded it.
Without PIC, any process which made exec() will have its own modified copy of
most code of the shared library. This is huge memory hog (and fatal for most
popular libraries, such as libc).
So, if you have no strong reason to compile shared library without PIC,
you should compile it with PIC (-fpic, or even -fPIC).
But, if execution speed (except startup) is critical to the application,
and there won't be many programs separately started using exec(),
you can make it non-PIC. If startup speed is also critical, consider
to link statically.
PIC can make library quite slower. For x86, libperl and Linux, it's about 30%
(not my benchmarks).

FM>  My experience in the
FM> past has been just to compile without shared.   In that
FM> case, calling the program is straightforward.  Just type
FM> the name of the executable.  With matlab, however, I
FM> compile it using their compiler (which does alot of other
FM> things beside just invoking gcc).  In particular, they add
FM> extra  switches:

FM>      -shared
FM>      -Wl,-M,${MATLAB}/extern/lib/sol2/mexFunction.map

FM> The -shared is obvious, and the -Wl is for the linker.
FM> I never used the linker explicitly before, relying on gcc to
FM> pull it all together.  Now, I'm looking at "man ld", which
FM> is the sunOS5.8 man page, and I'm not sure if it is the same
FM> one that gcc uses.  Is there any reason to think otherwise?

It isn't subject to make huge thinking, it is trivially testable.
Run gcc of any test example (even "Hello world") with -v.
Its verbose output will contain command line used to call linker, among other
information.
But, as -M for GNU ld means "print the map", I think your gcc uses SunOS ld.

FM> In the end, I'm still left with the question of how to
FM> invoke a shared library function outside of matlab.
FM> This is for the sake of speed comparison with the
FM> nonshared version, as the nonshared version is run
FM> from outside of matlab.

Trivial program will be similar to
main() {
  int (*func)(int);
  lib = dlopen( "yourlib.so", RTLD_LAZY );
  if( !lib ) { fprintf( stderr, "dlopen(): %s\n", dlerror() ); return 1; }
  func = dlsym( lib, "function" );
  if( !func ) { fprintf( stderr, "dlsym(): %s\n", dlerror() ); return 1; }
  printf( "%d\n", func(1) );
}

Rewrite it to your system and your function specifics.

FM> To get a grip on shared functions, I looked at the ld man
FM> page for the above -Wl switch.  It talks about mapfiles, and
FM> refers to "Linker and Libraries Guide" for an explanation,
FM> which I found on the web.  It's one hefty document.  All I
FM> want to know is whether execution speed and optimizability
FM> is affected.  I don't intend to actually dabble with the linker.

Than, mapfile isn't important for you.


-netch-