1.4.6: Build problem with doc/yat2m

[Marcus Brinkmann]

Hi Moritz,

At Mon, 22 Jan 2007 08:03:12 +0100,
Moritz Barsnick <moritz at barsnick.net> wrote:
> On Wed, Jan 17, 2007 at 20:28:26 +0100, Marcus Brinkmann wrote:
> 
> > > doc/yat2m now uses the new $(CC_FOR_BUILD) [*]. This is generally okay,
> > > but it totally ignores if I explicitly set LDFLAGS which are _required_
> > > for building.
> > 
> > As it should, as LDFLAGS is only relevant to the host environment.
> 
> I guess in a cross environment, LDFLAGS et.al. is ambiguous, and
> autoconf provides ways of providing differing flags for host and
> target.

It's not ambiguous.  LDFLAGS et al are for files compiled for the host
architecture, and not for the build architecture.  As these are
(potentially) two completely different environments, they must not be
mixed.  Other restrictions are for example that source files built for
the build architecture must not include "config.h".

Unfortunately, autoconf support for compiling programs to be run on
the build architecture is limited, so there is no canonical variable
to set.  The GNU world seems to settle on FOO_FOR_BUILD, though (see
for example gdb sources), with some flags, like warning switches,
included in all FOO's.

> But I'm in a non-cross environment. My LDFLAGS are valid for host and
> target.

I hope you agree that we can not write our source code so that it
works in your environment, but is broken in many other environments.
 
> > > (icc). This compiler creates binaries which depend on a certain dynamic
> > > lib (libimf.so) if not explicitly told to link that lib statically
> > > (with the -i-static LDFLAG).
> > 
> > What's the problem in having that dependency for yat2m?  Note that it
> > is not an installed program (see below).
> 
> Well, the RPATH or LD_LIBRARY_PATH don't need to be set, for one. And I
> do not want this dependency for my target.

Please let's say "host" here and not "target", because target has
already another meaning in Canadian-cross compilation environments
(three different architectures, build, host and target).

You should not have a dependency for your host by setting RPATH and
LD_LIBRARY_RPATH for your build system.  Setting LDFLAGS as you did
will prevent this successfully.  The only programs that will have such
a dependency are the tools used during the build (in this case yat2m).
These are not installed programs.

> > The drawback is that it is wrong, and can break down in cross
> > compilation settings (the only ones where CC_FOR_BUILD makes sense
> > anyway).  If this is really needed (please explain why), you have the
> > option to define CC_FOR_BUILD as above, which will only generate a few
> > warnings because it's not used often, or we can add an
> > LDFLAGS_FOR_BUILD which you would have to define in addition.
> 
> Which means that, in a non-cross environment, I need to set specific cross
> flags. This complicates things. I don't care much, I'm a hacker at
> heart. But non-cross builds of autoconf'd tools usually "just work
> (TM)", but not in this case.

The reason they don't work in your case is that you have a broken
environment that requires extra flags to be passed to the build (and
host) compiler to work.  Specifically, you suppress the
LD_LIBRARY_PATH environment variable that is necessary.  I can
understand the reason to do so (it helps to catch undesired run-time
dependencies), but if you choose to set up such an environment, you
will have to deal with the extra costs that this entails.

Note that the reasons you have to specify LDFLAGS are quite different
from the reasons to have to specify LDFLAGS_FOR_BUILD.  Therefore it
makes sense that you have to specify two variables, not one, even if
they end up holding the same value.

> IM ever so HO, non-cross builds should work easily, and cross builds
> need to evaluate all the special host vs. target stuff. But basically
> not in my case, I would have thought.

But you should be cross compiling: Your build architecture is the
intel compiler architecture, while your host architecture is the
sanitized environment without dependencies on the run-time of the
intel compiler.

The reason you have problems is that you crippled your build
architecture intentionally, to make it look more like the host
architecture, but without changing the compiler.  This does not mean
that you are not cross-compiling, though, it just makes it less
obvious that you are.

> I'll just hack around with my build environment's LD_LIBRARY_PATH, and
> make a note to assume any program _could_ require this sooner or
> later... *shrug*

I think that this is the right solution.  The bad thing is that you
may encounter other problems with packages which are not correctly set
up for such a "cross" compilation setup as yours.
 
However, note that I have no objections to do both: There are good
reasons to support LDFLAGS_FOR_BUILD, and we can add them to the
source.  It would be great if you could submit a patch for that which
is already tested in your environment, then we avoid an extra
turn-around to get a possible fix tested.

Thanks,
Marcus

g10 Code GmbH       http://g10code.com      AmtsGer. Wuppertal HRB 14459
Hüttenstr. 61                               Geschäftsführung Werner Koch
D-40699 Erkrath  -=- The GnuPG Experts -=-  USt-Id DE215605608