Re: trouble with installation of systemtap3-0 on Ubuntu 14.04

[Arkady <larytet at gmail dot com>]

On Thu, Jan 26, 2017 at 11:25 PM, David Smith <dsmith@redhat.com> wrote:
> On 01/26/2017 02:54 PM, Arkady wrote:
>> In my case this is
>> 116: 0000000000003a30    49 FUNC    GLOBAL DEFAULT   11
>> json_object_object_get_ex
>>
>> Symlink to /usr/lib/x86_64-linux-gnu/libjson-c.so.2.0.0
>> Package config
>>
>> prefix=/usr
>> exec_prefix=${prefix}
>> libdir=${prefix}/lib/x86_64-linux-gnu
>> includedir=${prefix}/include
>>
>> Name: json-c
>> Description: JSON implementation in C
>> Version: 0.11.99
>> Requires:
>> Libs:  -L${libdir} -ljson-c
>> Cflags: -I${includedir}/json-c
>
> Hmm, ok. Let's try the following to see what command is being run to
> link stapio - "make -n stapio". On my system, the output looks like (run
> from the 'staprun' directory):
>
> ====
> # make -n stapio
> rm -f stapio
> echo "  CCLD    " stapio;gcc -Wall -Wextra -Werror -Wunused -W
> -Wformat=2  -g -O2 -fstack-protector-all -D_FORTIFY_SOURCE=2   -o stapio
> stapio.o mainloop.o common.o ctl.o relay.o relay_old.o monitor.o
> libstrfloctime.a -lpthread -ljson-c   -lpanel -lncurses -ltinfo
> ====
>
> The above output makes sense:
>
>   gcc {other options} -o stapio {bunch of .o files} {libraries} -ljson-c
> {other libraries}
>
> Hopefully we'll see something similar with your output.
>
Same here

$ make -n stapio

rm -f stapio

echo "  CCLD    " stapio;gcc -Wall -Wextra -Werror -Wunused -W
-Wformat=2 -ljson-c -lncurses -ltinfo -g -O2 -fstack-protector-all
-D_FORTIFY_SOURCE=2   -o stapio stapio.o mainloop.o common.o ctl.o
relay.o relay_old.o monitor.o libstrfloctime.a -lpthread

When I try to run the line
gcc -Wall -Wextra -Werror -Wunused -W -Wformat=2 -ljson-c -lncurses
-ltinfo -g -O2 -fstack-protector-all -D_FORTIFY_SOURCE=2   -o stapio
stapio.o mainloop.o common.o ctl.o relay.o relay_old.o monitor.o
libstrfloctime.a -lpthread

I am getting

/home/arkady/systemtap-3.0/staprun/monitor.c:151: undefined reference
to `json_object_object_get_ex'
/home/arkady/systemtap-3.0/staprun/monitor.c:153: undefined reference
to `json_object_get_string'
monitor.o: In function `comp_state':
/home/arkady/systemtap-3.0/staprun/monitor.c:102: undefined reference
to `json_object_object_get_ex'
.....

/home/arkady/systemtap-3.0/staprun/monitor.c:151: undefined reference
to `json_object_object_get_ex'
/home/arkady/systemtap-3.0/staprun/monitor.c:152: undefined reference
to `json_object_object_get_ex'
/home/arkady/systemtap-3.0/staprun/monitor.c:153: undefined reference
to `json_object_get_string'
/home/arkady/systemtap-3.0/staprun/monitor.c:153: undefined reference
to `json_object_get_string'
monitor.o: In function `comp_state':
/home/arkady/systemtap-3.0/staprun/monitor.c:101: undefined reference
to `json_object_object_get_ex'
/home/arkady/systemtap-3.0/staprun/monitor.c:102: undefined reference
to `json_object_object_get_ex'
....
I attached the whole output.



> I've also attached a small test program. For me it compiles/links
> correctly with:
>
> # gcc -o jsonc-test jsonc-test.c -ljson-c

No errors, gcc created an executable jsonc-test.

>
> Does it work for you?
>
>> On Thu, Jan 26, 2017 at 10:40 PM, David Smith <dsmith@redhat.com> wrote:
>>> On 01/26/2017 01:38 PM, Arkady wrote:
>>>> On Thu, Jan 26, 2017 at 7:43 PM, David Smith <dsmith@redhat.com> wrote:
>>>>> On 01/26/2017 05:17 AM, Arkady wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This thread is probably the closest to the problem I experience.
>>>>>>
>>>>>> I need --monitor support in the stap. I am trying to compile the 3.0 release
>>>>>> On my Ubuntu 4.4.0-59-generic
>>>>>>
>>>>>> make[3]: Entering directory '/home/arkady/systemtap-3.0/staprun'
>>>>>>   CCLD     stapio
>>>>>> monitor.o: In function `comp_name':
>>>>>> /home/arkady/systemtap-3.0/staprun/monitor.c:151: undefined reference
>>>>>> to `json_object_object_get_ex'
>>>>>> I have ./lib/x86_64-linux-gnu/libjson.a and the library contains
>>>>>> json_object_object_get_ex
>>>>>> ...................
>>>>>>
>>>>>> What am I missing?
>>>>>
>>>>> Am I correct in thinking that libjson is installed in your home
>>>>> directory somewhere and isn't a system library? If so, that might be
>>>>> your problem. We can probably pass more options to configure to add that
>>>>> directory to the link search path.
>>>>>
>>>>> Another possibility is that the link is looking for a shared library
>>>>> (.so) and you've got a static library (.a).
>>>>>
>>>>
>>>> This is what I have
>>>> /usr/lib/x86_64-linux-gnu/libjson-c.so
>>>> /usr/lib/x86_64-linux-gnu/libjson-c.a
>>>> /usr/lib/x86_64-linux-gnu/libjson-c.so.2
>>>
>>> So I was wrong about the library being installed in your home directory.
>>>
>>>> Can it be an order of the object files and libraries?
>>>
>>> I'd doubt it. I wonder if we've got a json-c version problem. Let's see
>>> if your shared library has that symbol in it. When I run "readelf -Ws"
>>> on mine, I see the following:
>>>
>>> ====
>>> # readelf -Ws /lib64/libjson-c.so | fgrep json_object_object_get_ex
>>>    115: 0000000000003790    49 FUNC    GLOBAL DEFAULT   11
>>> json_object_object_get_ex
>>> ====
>>>
>>> What does yours return?
>>>
>>> Also, what version of json-c do you have? I've got json-c-0.12-7.
>>>
>>> --
>>> David Smith
>>> dsmith@redhat.com
>>> Red Hat
>>> http://www.redhat.com
>>> 256.217.0141 (direct)
>>> 256.837.0057 (fax)
>
>
> --
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)

Attachment: gcc.err
Description: Binary data