Re: AW: AW: AW: Re: tinterval - operator problems on AIX

Peter Eisentraut <peter_e@gmx.net> writes:

> > > This would seem to be the right answer, but unfortunately Autoconf is not
> > > smart enough to detect marginal cross-compilation cases in all situations.
> > > Someone had zlib installed in a location where gcc would find it (compiles
> > > okay) but the run-time linker would not (does not run).  This is not
> > > detected when AC_PROG_CC runs, but only later on after you have checked
> > > for the libraries.
> >
> > Hmmm.  I would not describe that as a cross-compilation case at all.
> > The build machine and the host machine are the same.
> 
> Only for small values of "same". ;-)  Sameness is not defined by the names
> being spelled identically or the physical coincidence of the hardware.
> There are a million things you can do to a system that supposedly preserve
> binary compatibility, such as installing vendor patches or changing a
> setting in /etc.  But if you run a test program is such a situation you're
> testing the wrong system.

I believe that terminology is important in technical issues, and in
any case I'm pedantic by nature.  So I am going to disagree.  When you
build a program on the system on which it is going to run, that is not
cross-compilation.  I agree that if you build a program on one system,
and then copy it (either physically or via something like NFS) to
another system, and run it on that other system, then that may be
cross-compilation.

It may be that the program in this case was being moved from one
machine to another, and I missed it.  However, unless that was the
case, a difference in search path between the compiler and the runtime
linker is not a cross-compilation issue.  A difference in where a
library appears from one machine to another is a cross-compilation
issue.

I believe that it is important to describe problems correctly in order
to understand how to fix them correctly.  If the problem is ``autoconf
does not correctly diagnose a case of cross-compilation,'' that
suggests one sort of fix.  If the problem is ``the compiler and the
runtime linker have different search paths,'' that suggests a
different sort of fix.


To return to the issue which started this thread, I believe it was an
issue concerning the behaviour of the mktime library call.  The
behaviour of that library call is not going to be affected by the
location of a shared library.  The approach I suggested should suffice
to address the particular problem at hand.  Do you disagree?


The issue in which the compiler and the runtime linker use different
search paths is fixed by either changing the compiler search path, to
by default only choose shared libraries from directories which the
runtime linker will search, or by changing the library installation
procedure, either put the library in /usr/lib, or on systems which
support ld.so.conf arrange to put the directory in ld.so.conf.

Note that if you link with -lz, at least some versions of the GNU
linker will issue a warning that the library will not be found by the
runtime linker.

Ian