Re: Weird behavior when linking libgdd

[Andrew Johnson <anj@aps.anl.gov>]

Hi Ralph

On 05/04/2015 10:26 AM, Ralph Lange wrote:
> When building EPICS Base and installing in a different place using
> INSTALL_LOCATION, the linked libgdd contains the directory where it was
> installed to, as a grep'able string, while all the other libraries in
> Base don't. (Currently building 3.15.2.rc1, but other versions are the
> same.)

> I have been poking around for quite a while, but I can neither find the
> difference between gdd and all the other libraries, nor am I able to
> suppress the embedded build-path.
> Any ideas?

Ok, lets try this:
INSTALL_LOCATION=/home/phoebus/ANJ/TEMP/install-3.15

tux% strings libca.a | grep TEMP
tux$ strings libgdd.a | grep TEMP
/home/phoebus/ANJ/TEMP/install-3.15/include
/home/phoebus/ANJ/TEMP/install-3.15/include/os/Linux
/home/phoebus/ANJ/TEMP/install-3.15/include

Ok, I match your result. Note that the path to the build directory is
burned into all of the .a files, but that's not what you're complaining
about:

tux% strings libca.a | grep anj | uniq
/local/anj/base-3.15/src/ca/client/O.linux-x86_64

tux$ cd ../../src/ca/legacy/gdd/O.linux-x86_64
tux$ strings libgdd.a | grep TEMP
/home/phoebus/ANJ/TEMP/install-3.15/include
/home/phoebus/ANJ/TEMP/install-3.15/include/os/Linux
/home/phoebus/ANJ/TEMP/install-3.15/include
tux$ grep --binary-files=binary TEMP *.o
Binary file aitConvert.o matches
Binary file dbMapper.o matches
tux$ strings aitConvert.o | grep TEMP

Huh? Oh, strings is being clever...

tux$ strings -a aitConvert.o | less
...
../O.Common
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include
/usr/include/bits
/usr/include
/home/phoebus/ANJ/TEMP/install-3.15/include
aitConvert.cc
aitConvertGenerated.cc
aitHelpers.h
gddEnumStringTable.h
stddef.h
types.h
libio.h
aitTypes.h
aitConvert.h
epicsAlgorithm.h
stdio.h
...

Hmm, include directories, followed by a list of source and header files,
which exactly matches the include files for the .o file, is this debug
information? Yes, the TEMP strings disappear if I compile the .o file
without the -g option so this is debug information from the compiler;
it's actually found in the section .debug_line of the .o file although I
have no idea what that means.

Why is gdd different?

tux% strings libcas.a | grep TEMP
/home/phoebus/ANJ/TEMP/install-3.15/include
/home/phoebus/ANJ/TEMP/install-3.15/include/os/Linux
/home/phoebus/ANJ/TEMP/install-3.15/include
/home/phoebus/ANJ/TEMP/install-3.15/include/os/Linux
/home/phoebus/ANJ/TEMP/install-3.15/include
/home/phoebus/ANJ/TEMP/install-3.15/include/os/Linux
/home/phoebus/ANJ/TEMP/install-3.15/include
/home/phoebus/ANJ/TEMP/install-3.15/include/os/Linux
/home/phoebus/ANJ/TEMP/install-3.15/include
...

It isn't. 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.

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.

- Andrew

-- 
Light thinks it travels faster than anything but it is wrong.
No matter how fast light travels, it finds the darkness has
always got there first, and is waiting for it.
    -- Terry Pratchett, Reaper Man