Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Tue, 05 May 2015 09:43:49 +0200

Hi Andrew,

Wow.

I had almost forgot that circularity with gdd, and the trouble we had

some years ago trying to make the build reliable.

In my poking around I basically went down the same path, but I hadn't

seen the strings command trying to be clever, so I was puzzled with how

linking would add the path to the archive.

Great detective work!

On 04/05/2015 19:23, Andrew Johnson wrote:

[...]

It's just that you changed your INSTALL_LOCATION without doing
a 'make clean' (as did I) so most of your .o files were not recompiled
and all the include directories in them still listed relative paths to
the $(TOP)/include directory. The gdd .o files tend to get rebuilt more
often than other files because of the circular dependency on gddApps.h
which is why you saw this there.

The RPM check assumes the standard scenario where the 'build' target

builds and the 'install' target installs. So you can safely have the

debug information in the libraries contain the build location path,

because the install moves it to a different location - and that new

location is what the check-buildroot checks against.

I think you'll have to remove the -g options from your
configure/os/CONFIG_SITE.Common.linux-x86{,_64} files to remove the
embedded build path, and don't forget to 'make clean' as well.

Hm - I don't want to lose the debugging info.

Instead, I will plainly 'install' the gdd libraries into the staging

area, copying from the build, overwriting the ones that 'make

INSTALL_LOCATION=...' put there.

Now that I know it's safe to do so, that looks like the most appropriate

thing to do.

Thanks a *lot*,
~Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System