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
- Replies:
- Re: Weird behavior when linking libgdd Michael Davidsaver
- References:
- Weird behavior when linking libgdd Ralph Lange
- Re: Weird behavior when linking libgdd Andrew Johnson
- Navigate by Date:
- Prev:
Re: Weird behavior when linking libgdd Andrew Johnson
- Next:
Re: Weird behavior when linking libgdd Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Weird behavior when linking libgdd Andrew Johnson
- Next:
Re: Weird behavior when linking libgdd Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|