g++: Shared library, mapfiles, execution speed
Fred Ma
I'm converting a C++ program into a function that can be
called by an external application. Specifically, I will be
invoking it from a scientific computation package called
Matlab. It needs my program (main converted into an
actual function) to be compiled with the "gcc -shared"
option, which creates position-indepedent code.
My question is: is execution speed or optimizability
(gcc -O) affected by -shared? I'm not too sure how to
compare shared vs. nonshared. My experience in the
past has been just to compile without shared. In that
case, calling the program is straightforward. Just type
the name of the executable. With matlab, however, I
compile it using their compiler (which does alot of other
things beside just invoking gcc). In particular, they add
extra switches:
-shared
-Wl,-M,${MATLAB}/extern/lib/sol2/mexFunction.map
The -shared is obvious, and the -Wl is for the linker.
I never used the linker explicitly before, relying on gcc to
pull it all together. Now, I'm looking at "man ld", which
is the sunOS5.8 man page, and I'm not sure if it is the same
one that gcc uses. Is there any reason to think otherwise?
In the end, I'm still left with the question of how to
invoke a shared library function outside of matlab.
This is for the sake of speed comparison with the
nonshared version, as the nonshared version is run
from outside of matlab.
To get a grip on shared functions, I looked at the ld man
page for the above -Wl switch. It talks about mapfiles, and
refers to "Linker and Libraries Guide" for an explanation,
which I found on the web. It's one hefty document. All I
want to know is whether execution speed and optimizability
is affected. I don't intend to actually dabble with the linker.
Could a kindly programmer provide some expert commentary
on this? I'm using g++ 3.2.1 on solaris 8. Matlab r13 (though
I doubt that matters).
Thanks.
Fred
Markus Gyger
> My question is: is execution speed or optimizability
> (gcc -O) affected by -shared?
PIC might execute slightly slower (less registers might be
available for optimizations and address calculations might
take more steps).
> -Wl,-M,${MATLAB}/extern/lib/sol2/mexFunction.map
> To get a grip on shared functions, I looked at the ld man
> page for the above -Wl switch. It talks about mapfiles, and
Regarding speed, map files affect mostly the startup time only.
> I'm using g++ 3.2.1 on solaris 8.
You might want to take a look at gcc2c and use it with the current
(production) Sun C compiler for maximum speed optimization:
http://soldc.sun.com/migration/linux/gcc2c_tool.html
http://access1.sun.com/s1sprod/
Markus
Greg Menke
> My question is: is execution speed or optimizability
> (gcc -O) affected by -shared? I'm not too sure how to
> compare shared vs. nonshared. My experience in the
> past has been just to compile without shared. In that
> case, calling the program is straightforward. Just type
> the name of the executable. With matlab, however, I
> compile it using their compiler (which does alot of other
> things beside just invoking gcc). In particular, they add
> extra switches:
>
> -shared
> -Wl,-M,${MATLAB}/extern/lib/sol2/mexFunction.map
I've not heard of a case where there is any significant difference
between position independent and non-position independent. I suspect
most code ends up compiled independent in any case. Perhaps it could
change something in how registers are allocated, but that would be
something highly architecture specific.
static vs shared is used to create either a dynamically or statically
linked library. A static library ends up being an archive of .o files
that are included in a executable when its linked, whereas a
dynamically linked library can be attached to an executable at
runtime. Optimization is not affected because shared/static is more
of a linker issue than a compiler issue. Once the code is in memory
and the fixups applied to all the symbols, there isn't any difference.
When you compile an executable, you're not creating a library, so
shared/static are not applicable.
>
> The -shared is obvious, and the -Wl is for the linker.
> I never used the linker explicitly before, relying on gcc to
> pull it all together. Now, I'm looking at "man ld", which
> is the sunOS5.8 man page, and I'm not sure if it is the same
> one that gcc uses. Is there any reason to think otherwise?
A map file is simply a textual representation of some of addresses &
symbols in the output executable. Perhaps Matlab is reading the map
file to get symbol information or some such. If you're curious about
looking at compiled code, use objdump -dt against your .o file.
Here, ld is not being invoked separately, the -Wl tells gcc to pass
along the following parameter when it invokes ld. You definately
don't want to be playing around with ld until you know you need to.
Gregm
Valentin Nechayev
(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-
Fred Ma
Actually, I want to stick with gcc because I want transparency
between solaris8 and Win2K/Cygwin. Thanks for the suggestions.
Fred
Fred Ma
> I've not heard of a case where there is any significant difference
> between position independent and non-position independent.
That's reassuring.
> I suspect
> most code ends up compiled independent in any case. Perhaps it could
> change something in how registers are allocated, but that would be
> something highly architecture specific.
>
> static vs shared is used to create either a dynamically or statically
> linked library. A static library ends up being an archive of .o files
> that are included in a executable when its linked, whereas a
> dynamically linked library can be attached to an executable at
> runtime. Optimization is not affected because shared/static is more
> of a linker issue than a compiler issue. Once the code is in memory
> and the fixups applied to all the symbols, there isn't any difference.
Great.
> When you compile an executable, you're not creating a library, so
> shared/static are not applicable.
>
> >
> > The -shared is obvious, and the -Wl is for the linker.
> > I never used the linker explicitly before, relying on gcc to
> > pull it all together. Now, I'm looking at "man ld", which
> > is the sunOS5.8 man page, and I'm not sure if it is the same
> > one that gcc uses. Is there any reason to think otherwise?
>
> A map file is simply a textual representation of some of addresses &
> symbols in the output executable. Perhaps Matlab is reading the map
> file to get symbol information or some such. If you're curious about
> looking at compiled code, use objdump -dt against your .o file.
>
> Here, ld is not being invoked separately, the -Wl tells gcc to pass
> along the following parameter when it invokes ld. You definately
> don't want to be playing around with ld until you know you need to.
>
> Gregm
Well, thanks for the confirmation that I shouldn't be poking around
with ld unnecessarily. I wasn't looking forward to spending loads
of timing ramping up on a new tool.
Fred
Fred Ma
> `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.)
I can live with long startup time. The execution time is much longer,
so that's the important thing.
> 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.
Well, thanks for the advice. It wasn't obvious to me how to
obtain the information, but your suggestion to use -v revealed
that it was the solaris linker.
> 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) );
> }
OK, that's quite a bit of new material (can't say I recognize
any of it). I'll have to do some digging and reading before
I make use of it. Thanks.
Fred
Fred Ma
> The gccopts for sol2 in R13 uses the compiler to link. It is always
> better to use the compiler to link because only the compiler knows what
> libraries it wants to link against.
>
> The map file shipped with MATLAB is used to mark only the functions
> mexFunction and mexVersion as accessible from outside the MEX
> executable. It does not affect runtime at all. You can successfully
> build MEX-files without using it.
I need the mexFunction gateway function. I guess one could do
without it, if one were a guru in under-the-hood details of interfacing
matlab and C/C++, so that excludes me.
> On Solaris, you can build shared libraries that are not pic but in the
> distant past I have gotten into trouble with them so since that time,
> MEX-files by default are built pic. SUN's always builds their own
> shared libraries as pic.
Yes, I was thinking of PIC and shared libraries as synonymous,
even though I am told that they are not. I'm not too interested in
their differences, I was just curious about whether my code will
run any slower when compiled via the mex way, but I'll find out
once I've finished recoding (getting familiar with passing/returning
structs and extracting parameters, changing all references to
cout and cerr to use matlab printing functions, changing all
exit(EXIT_FAILURES) to throws that are caught by my toplevel
function, etc..). I was hoping to get an idea of whether the interfacing
was all worth it, since my matlab modules only do graphing to
monitor progress, and digesting results returned by many runs of
my C++ number cruncher. Responses in the other newsgroups
seem to indicate that PIC doesn't adversely affect speed.
Fred
Markus Gyger
> Markus Gyger wrote:
> > You might want to take a look at gcc2c and use it with the current
> > (production) Sun C compiler for maximum speed optimization:
> >
> > http://soldc.sun.com/migration/linux/gcc2c_tool.html
> > http://access1.sun.com/s1sprod/
>
> between solaris8 and Win2K/Cygwin.
gcc2c is just a patch for gcc's backend so that it produces
ISO C code that is then fed to another optimizing C compiler.
Kind of like the early C++ compilers/translators worked (cfront).
Markus
Fred Ma
Hi, Markus,
I took a look at the description. It looks interesting.
Natural question is why not just use sun's CC directly
when compiling on solaris?
There is another factor that I have to consider. That
is the fact you have to modify the build of gcc. It took
about a week to learn enough to try (four
times) to build my own gcc (I am nonadministrator).
This included all the facilities required to test it. It never
passed the tests without many errors, different errors
each time. Since I couldn't tell which ones were important,
I didn't install it; my concern was that I couldn't tell which
files to remove in order to uninstall everything. In the end
I asked my sysadmin to install premade binaries for solaris.
So building gcc is a bit of a problem.
As soon as I finish recoding for matlab, I can do a speed
comparison to confirm that compiling with PIC and as shared
does not adversely affect executio speed. 30% speed
increase from using gcc2c is somewhat significant, and
I'll see if in the future, time permits me to ramp up on what's
necessary to make it work. Thanks for the suggestion.
Fred
Philip Brown
>Markus Gyger wrote:
>> You might want to take a look at gcc2c and use it with the current
>> (production) Sun C compiler for maximum speed optimization:
>
>Actually, I want to stick with gcc because I want transparency
>between solaris8 and Win2K/Cygwin.
you should have no problems using forte for solaris 8 and gcc on cygwin.
It's easy taking source code developed under forte CC, and recompiling with
g++. Usually, (almost always) there's nothing extra to do.
The problem is when you try to go the other way.
--
http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
Organized by the author of pkg-get
[Trim the no-bots from my address to reply to me by email!]
S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
http://www.spamlaws.com/state/ca1.html
Fred Ma
I do recall years ago when I last used C++, I was in fact making
minor mods to enable compiling with gcc on the suns and HP's CC.
That was on HPUX. For now, I just want to understand what
coding practices affect speed, in principle, and worry about tweaking
based on compilers/platform later. I may decide to forgo some of
those for cross-platform portablility e.g. if it involves time to tweak
stuff everytime I migrate from cygwin gcc to solaris forte, I may decide
just to stick with gcc because of its ubiquity.
By the way, gcc has a handy --version switch, but cc on the sun
doesn't. Is there a way to check beyond any doubt what compiler
it is?
Fred
Barbie LeVile
Fred Ma <f...@doe.carleton.ca> wrote:
>
> By the way, gcc has a handy --version switch, but cc on the sun
> doesn't. Is there a way to check beyond any doubt what compiler
> it is?
>
cc -V
--
Barbie - Prayers are like junkmail for Jesus
I have seen things you lusers would not believe.
I've seen Sun monitors on fire off the side of the multimedia lab.
I've seen NTU lights glitter in the dark near the Mail Gate.
All these things will be lost in time, like the root partition last week.
Time to die.
Casper H.S. Dik
>By the way, gcc has a handy --version switch, but cc on the sun
>doesn't. Is there a way to check beyond any doubt what compiler
>it is?
"cc -V" or "CC -V"
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Fred Ma
Thanks, Barbie and Casper. Our department's sun cc is
WorkShop Compilers 5.0 98/12/15 C++ 5.0. It isn't Forte
(which has changed names to Sun ONE Studio 7, according
to a web search), the one mentioned by Philip Brown. Unless
it goes by more than one name.
Fred
Mumit Khan
Fred Ma <f...@doe.carleton.ca> wrote:
>
>Thanks, Barbie and Casper. Our department's sun cc is
>WorkShop Compilers 5.0 98/12/15 C++ 5.0. It isn't Forte
>(which has changed names to Sun ONE Studio 7, according
>to a web search), the one mentioned by Philip Brown. Unless
>it goes by more than one name.
Your time may be better served if you take the time to browse Sun's
extensive online documentation (docs.sun.com) and get a better feel
for what you have and what you need. For more information on Sun
Forte/ONE Studio tools, go to http://www.sun.com/workshop/.
The C++ compiler in Workshop 5.x is so ancient that it's useless in
today's world. Sun ONE Studio 7 does have a good C++ compiler; Forte
6 update 2 is the oldest you want to use at this point, at least for
any new code (make sure you apply all the patches available from the
workshop site). If you're using it on a University machine, Forte/ONE
Studio are available from Sun at a *very* reasonable price.
Do please watch the all the cross-posting! Followup set to comp.unix.solaris
only.
Regards,
Mumit
Fred Ma
Apologies for the cross-posts. The newsgroup lists seemed to be
appropriate for the initial post, and the topic has since branched into
narrow subtopics. My standard practice has been to avoid fragmenting
a thread once started. For this subthread, I've only left two newsgroups.
Due to lack of time, I will do what coding practice allows on gcc to
get execution speed. I spent a week as a nonadministrator trying
to build gcc (including learning about and installing auxiliary tools
to test it). Due to high test failures, I asked my sys admin to
install the binaries. I'm very adverse to getting any more involved
in tool/environment setup until I get my thesis, unless there is
an impediment that takes too much effort to work around.
The purpose of my original post was to a rough idea of how much
performance I'm sacrificing by making my program callable by
matlab, which requires that it be compiled as shared and PIC.
From the responses, and time constraints, I decided to stick with
gcc. That also leaves open the possibility of setting up conditional
compilation to compile on cygwin for execution that does not
make use of matlab, and for execution on solaris that can make
use of matlab.
Thanks for your information above.
Fred
Philip Brown
>..
>Due to lack of time, I will do what coding practice allows on gcc to
>get execution speed.
I suggest doing your work with "g++ -pedantic -ansi", so you have the
widest amount of options in the future, without having to rewrite your
source code.
Alan Coopersmith
|Thanks, Barbie and Casper. Our department's sun cc is
|WorkShop Compilers 5.0 98/12/15 C++ 5.0. It isn't Forte
|(which has changed names to Sun ONE Studio 7, according
|to a web search), the one mentioned by Philip Brown. Unless
|it goes by more than one name.
Sun's compiler line goes by a different name in every other release.
WorkShop 5.0 is the version before Forte 6 which was the version before
SunOne 7, with SunOne 8 coming out shortly.
--
________________________________________________________________________
Alan Coopersmith al...@alum.calberkeley.org
http://www.CSUA.Berkeley.EDU/~alanc/ aka: Alan.Coo...@Sun.COM
Working for, but definitely not speaking for, Sun Microsystems, Inc.
Fred Ma
> On Sat, 15 Mar 2003 20:49:28 -0500, f...@doe.carleton.ca wrote:
> >..
> >Due to lack of time, I will do what coding practice allows on gcc to
> >get execution speed.
>
> I suggest doing your work with "g++ -pedantic -ansi", so you have the
> widest amount of options in the future, without having to rewrite your
> source code.
Thanks for the suggestion, Philip. It looks like my code conforms
to the standard. No gush of warnings.
Fred
Bart Smaalders
code will manifest itself in the following areas (on SPARC):
1) The increased number of instructions can be seen
in very simple programs that fit in I & D caches
since E$ and memory latencies don't hide anything.
2) Very simple leaf routines that access global data will
now require a register window as a result of how they
find the GOT (global offset table). This can increase
register window spill fill traps in some cases; typically
seen with C++ "data hiding" functions that insist on
using global flags to control their behavior. If the data
objects being used are large, including a pointer to a structure
containing important global state can significantly improve
performance of trivial functions. In C:
Rather than
int
get_count(myobj_t * foo)
{
if (debug_flag) {
...
}
return (foo->count);
}
add a pointer to myobj_t to point to global state and get
int
get_count(myobj_t * foo)
{
if (foo->global_data->debug_flag) {
...
}
return (foo->count);
}
Where possible, one can of course inline the accessor functions,
but this eliminates some of the advantages of using them in the
first place.
3) In PIC code, all calls to non-local functions must be done
through a PLT (procedure linkage table), as the address of
the target function is not known at compile time. These PLT entries
initially point into the dynamic linker, and are then resolved
the first time they're called and the code in the PLT is updated
to call the function directly. However, calling global functions
outside the shared library will always involve 2 function calls,
so we end up w/ a few more cycles _and_ more itlb pressure.
Note that we can optimize the number of global symbols by scoping
the library so that only externally used symbols remain global
(see Linker and Library Manual at http://docs.sun.com). If you're
not interposing on symbols in the library, the library may also be
linked w/ -Bsymbolic, although this can cause problems w/ some C++
environments (sigh)).
In most cases, these effects are not significant. Sometimes, however,
they can cause a lot of head scratching.
- Bart
Fred Ma <f...@doe.carleton.ca> wrote in message
Drazen Kacar
> If you're not interposing on symbols in the library, the library may
> also be linked w/ -Bsymbolic,
Any reason why you're mentioning -Bsymbolic and not -Bdirect?
--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@willfork.com
Fred Ma
Hi, Bart,
A lot of that went over my head. But I appreciate the time you
took to explain it. I ran a test case on an older version of my
program (non of the PIC/shared compilation to link to matlab),
and it rand about 20% faster. But that could be due to a very
arduous parameter passing protocol I use to check any
data passed from matlab. For each argument, I do a brute
force comparison with all simulation parameter names to see
if it is a valid parameter specification, and checking types and
array sizes on top of that. I will do something smarter, like
STL's map container, at a later time.
Fred
Bart Smaalders
> Bart Smaalders wrote:
>
> > If you're not interposing on symbols in the library, the library may
> > also be linked w/ -Bsymbolic,
>
> Any reason why you're mentioning -Bsymbolic and not -Bdirect?
Because -Bdirect tells ld.so to remember where to find symbols (eg
what library to search in), whereas -Bsymbolic tells ld to
convert any references to global symbols that end up resolving at link
time to the current library to a local binding as if the symbol were static.
This cuts down on run-time overhead by avoiding the call through the PLT.
From the fine man page:
-B direct
Establishes direct binding information by recording
the relationship between each symbol reference and the
dependency that provides the definition. The runtime
linker uses this information to search directly for
the symbol in the associated object rather than to
carry out its default symbol search. Direct binding
information can only be established to dependencies
specified with the link-edit. Thus, you should use the
-z defs option. Objects that wish to interpose on sym-
bols in a direct binding environment should identify
themselves as interposers with the -z interpose
option. The use of -B direct enables -z lazyload for
all dependencies.
-B symbolic
In dynamic mode only. When building a shared object,
binds references to global symbols to their defini-
tions, if available, within the object. Normally,
references to global symbols within shared objects are
not bound until runtime, even if definitions are
available, so that definitions of the same symbol in
an executable or other shared object can override the
object's own definition. ld will issue warnings for
undefined symbols unless -z defs overrides.