EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Weird behavior when linking libgdd
From: Andrew Johnson <[email protected]>
To: <[email protected]>
Date: Mon, 4 May 2015 12:23:29 -0500
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

Replies:
Re: Weird behavior when linking libgdd Ralph Lange
References:
Weird behavior when linking libgdd Ralph Lange

Navigate by Date:
Prev: Re: Weird behavior when linking libgdd Michael Davidsaver
Next: Re: Weird behavior when linking libgdd Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Weird behavior when linking libgdd Michael Davidsaver
Next: Re: Weird behavior when linking libgdd Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·