Re: Weird behavior when linking libgdd

[Ralph Lange <Ralph.Lange@gmx.de>]

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