need setting LD_LIBRARY_PATH manually before running systemC models

[sonalidutta]

Hi,

 

I am working on Assertion Based Dynamic Verification of SystemC models. To expose some states of the kernel to the runtime monitors I am doing some minimal modification to the SystemC-2.3.0 kernel.

 

 

I added 4 new files:

       mon_prototype.cpp/h

       mon_observer.cpp/h

 

I also did some minimal modification(adding callbacks) to:

       sc_event.cpp/h

       sc_sim_context.cpp/h

       sc_object.cpp/h

       sc_thread_process.h

      

I did the required modification to : systemc-2.3.0/src/systemc.

 

 

For installation I modified:

 

1. /systemc-2.3.0/src/sysc/kernel/Makefile.am to add the new 4 files I have added to kernel (see above for detail)

2. /systemc-2.3.0/configure.in to add a new flag called -DDEBUG_PRINT_IN_SCHEDULER

 

Now I ran:

autoconf: This takes aclocal.m4 and configure.in as input and generates ./configure file as output.

automake: This takes configure.in and Makefile.am as input and generates Makefile.in as output.

 

Now I follow the steps in INSTALL file for the rest of the installation process.

 

The modified systemC got installed successfully at: modified_systemc-2.3.0/

 

Now I try to run a small systemC model adder using this modified SystemC. When I compile adder model with modified_systemc-2.3.0, it compiles without any warning or error. But when I run it, it gives me the following error:

 

#  ./addy

./addy: error while loading shared libraries: libsystemc-2.3.0.so: cannot open shared object file: No such file or directory.

 

But libsystemc-2.3.0.so is there at /modified_systemc-2.3.0/lib-linux64/libsystemc-2.3.0.so

 

So I got the following workaround:

 

 

# LD_LIBRARY_PATH=modified_systemc-2.3.0/lib-linux64

# export LD_LIBRARY_PATH

 

And now if I run ./addy, it runs fine.

 

This problem does not occur while running ./addy using unmodified version of SystemC 2.3.0. My guess is that I missed setting some default path while modifying the systemc-2.3.0. So the paths that should be set by default is not set be default and need manual setting.

 

Does anyone have any idea how I can fix it?

 

Thanks and Regards

Sonali

[apfitch]

Something must be setting LD_LIBRARY_PATH in the normal case ( the standard library, not your modified one).

 

Either LD_LIBRARY_PATH contains the path (which you say it doesn't).

 

Or the path is set in /etc/ld.so.conf

 

Or the Makefile system you're using uses -Wl, -rpath to dynamically set the path.

 

I suspect the Makefile. Have a look in your makefiles - if they're using -rpath, then you need to edit the option on -rpath to point to your modified library,

 

regards

Alan

[sonalidutta]

Dear Alan,
 
Thank you for your response.
 
Unmodified systemc-2.3.0 automatically sets LD_LIBRARY_PATH. I did grep -r "systemc-2.3.0" * in uninstalled systemc-2.3.0 package to identify the potential place where I need to modify to set LD_LIBRARY_PATH automatically in my modified version of systemc-2.3.0. Here is the result:
 
[root@localhost systemc-2.3.0]# grep -r "systemc-2.3.0" *
examples/tlm/build-msvc/Makefile.config:SYSTEMC = C:\SystemC\systemc-2.3.0\msvc80
examples/tlm/build-msvc/systemc.vsprops:                Value="C:\SystemC\systemc-2.3.0\msvc71"
examples/tlm/build-msvc/MakefileVC9.config:SYSTEMC = C:\SystemC\systemc-2.3.0\msvc90
examples/tlm/build-msvc/MakefileVC7.config:SYSTEMC = C:\SystemC\systemc-2.3.0\msvc71
examples/tlm/build-unix/Makefile.config:SYSTEMC_HOME        ?= /usr/local/systemc-2.3.0
examples/sysc/Readme_msvc80.txt:installation (e.g. C:\systemc-2.3.0\msvc80).
INSTALL:  1. Change to the top level directory (systemc-2.3.0)
INSTALL:     top level directory (systemc-2.3.0), configure the package e.g. as
INSTALL:        > ../configure --prefix=/usr/local/systemc-2.3.0
INSTALL:3. Select the 'New' icon and browse to: C:\systemc-2.3.0\msvc80\systemc\debug
INSTALL:5. Select the 'New' icon and browse to: C:\systemc-2.3.0\src
INSTALL:   the SystemC library:   ...\systemc-2.3.0\msvc80\systemc\debug'systemc.lib'
 
I do not think modifying any of the above will solve my issue.
 
Also regarding the Makefile I am using to run my adder model, I am not using -rpath or -WI. As you can see in my attached Makefile:
 
I only modify the path of SYSTEMC_HOME that gets added to INCLUDE_DIRS and LIBRARY_DIRS. Please have a look at my Makefile.
 
My guess is something I did not do (that I should have done!) while installing the modified systemc-2.3.0.
 
I did autoconf anf automake.
 
May be I need aclocal too! But aclocal gives me errors! So I did not do it.
 
Any insight?
 
Thanks
Sonali

 

 

 

It does not let me upload my Makefile. So I sopy paste it here:

 

 

****************************************************************************************************************

 

 

withobserver =     no
usemonitor0 =     no    # automatically generated safety



CC=        time /usr/bin/g++
TARGET_ARCH =     linux64

FLAGS = -O3 -w -Wno-deprecated \
        -DSC_INCLUDE_DYNAMIC_PROCESSES \
        -D_VERBOSE_GLOBAL \
        -D_MONITOR_REPORT_FAIL_IMMEDIATELY \
        -D_MONITOR_REPORT_PASS_IMMEDIATELY

VPATH =        /root/Desktop/CHIMP_ea/adders1

CUSTOM_LOCAL =     /usr/local
#SYSTEMC_HOME =    /root/Desktop/CHIMP_ea/systemc_with_modifications/systemc-2.2.0
SYSTEMC_HOME = /root/Desktop/CHIMP_ea/patched_systemc-2.3.0
#SYSTEMC_HOME = /root/Desktop/CHIMP_ea/systemc-2.3.0

## Include directories
INCLUDE_DIRS =     $(SYSTEMC_HOME)/include ./ $(VPATH)

INCDIR = $(INCLUDE_DIRS:%=-I %)

## Library directories
LIBRARY_DIRS =     $(SYSTEMC_HOME)/lib-$(TARGET_ARCH)

LIBDIR = $(LIBRARY_DIRS:%=-L %)

## SystemC static library
LIB_SC = -lsystemc \

## Other static libraries
LIB_OTHERS =

LIBS = $(LIBDIR) $(LIB_SC) $(LIB_OTHERS:%=-l%)

CFLAGS = $(FLAGS) $(INCDIR)

## Example .cc files
SRCS = $(wildcard ./*.cc )
HDRS = $(wildcard ./*.h  )
OBJS = adder.o debug_printer.o  driver.o  main.o


# Optional flags depending on the monitors we want to turn on/off
ifeq ($(withobserver), yes)
FLAGS += -DWITH_OBSERVER
endif

ifeq ($(strip $(usemonitor0)), yes)
FLAGS += -DMONITOR_0
OBJS += monitor.o
MAIN_DEPS += monitor.cc
endif



addy: $(OBJS) $(HDRS)
    $(CC) -o addy $(OBJS) $(LIBS)

main.o: main.cc $(HDRS) Makefile $(MAIN_DEPS)

etags:
    find . -name '*.[cc|c|h]' | xargs etags
    find $(INCLUDE_DIRS) -name '*.[cc|c|h]' | xargs etags -a

check:
    @echo $(HDRS)



#&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
#Standard Makefile stuff

.cpp.o:
    $(CC) $(CFLAGS) -c $<

.c.o:
    $(CC) $(CFLAGS) $(CPPFLAGS) -c $<

.cc.o:    
    $(CC) $(CFLAGS) -c $< -o $@




clean:    
    $(REMOVE)

distclean: clean
    /bin/rm -f \#* addy

lint:
    lint *.c

REMOVE = /bin/rm -f *~ .*~ *.BAK .*.BAK *.o logfile

#Standard Makefile stuff
#&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
 

 

[apfitch]

Hi Sonali,

  as an experiment I installed systemc-2.3.0 in my own directory. I then removed all references to Systemc LD_LIBRARY_PATH.  I then also

get a linker error like yours.

 

That's why I'm wondering why you do *not* get a linker error with your main build.

 

If you look in lib-linux64, do you see libsystemc.so and libsystemc.a for both your builds?

 

Can you build a simple example using

g++ -I/home/apf/systemc2.3.0/include/ -L/home/apf/systemc2.3.0/lib-linux64/  -Xlinker -rpath -Xlinker /home/apf/systemc2.3.0/lib-linux64/ hello_world.cpp -lsystemc

Obviously change all the paths to point to your normal and modified SystemC distribution.

 

Here's my little "hello world" program

 

#include "systemc.h"

SC_MODULE(Test) {

  void proc() {
    while (true) {
      cout << sc_time_stamp() << endl;
      wait(10, SC_NS);
    }
  }
 
  SC_CTOR(Test) {
    SC_THREAD(proc);
  }
 
};

int sc_main(int argc, char ** argv) {

  Test t("t");
  sc_start(100, SC_NS);
  return 0;
}
 

 

regards

Alan
 

[apfitch]

One other thing - what do you get with

 

ldd addy

in both cases?

 

regards

Alan

[dakupoto]

Hello,

There should be no confusion about LD_LIBRARY_PATH. It is a Linux runtime

environment variable, to be set right before the simulation is executed. We do

the following on a Fedora 17 machine.

To compile:

g++ -I. -I<absolute or relative path to SystemC 2.3.0 library/include -L.

-L<absolute or relative path to SystemC 2.3.0 library/lib-linux -o

<name of simulation executable> <SystemC executable source file name>

-lsystemc -lm

 

Provided the compilation step does not produce any errors, set the runtime

environment variable, by first finding out the Linux shell being used:

on bash shell:

export LD_LIBRARY_PATH=<absolute or relative path to SystemC 2.3.0 library/lib-linux

Now execute the simulation,

All of this is if SELinux is not activated, in which case it has to be de-activated

temporarily(for duration of simulation) in the root/super user mode, by using the

Linux ssyetm command 'setenforce'.

Hope that helps.

[sonalidutta]

Hi Sonali,

  as an experiment I installed systemc-2.3.0 in my own directory. I then removed all references to Systemc LD_LIBRARY_PATH.  I then also

get a linker error like yours.

 

That's why I'm wondering why you do *not* get a linker error with your main build.

 

My guess is that I have both systems-2.3.0 and modified_systemc-2.3.0 in the same path. So the linker by default finds the .so files in systemc-2.3.0/lib-linux64 and it does not complain. 

 

But the adder Makefile points to the modified_systemc-2.3.0 and that is when it gives error.

If you look in lib-linux64, do you see libsystemc.so and libsystemc.a for both your builds?

 

 

Yes. 

 

Can you build a simple example using

g++ -I/home/apf/systemc2.3.0/include/ -L/home/apf/systemc2.3.0/lib-linux64/  -Xlinker -rpath -Xlinker /home/apf/systemc2.3.0/lib-linux64/ hello_world.cpp -lsystemc

Obviously change all the paths to point to your normal and modified SystemC distribution.

 

Here's my little "hello world" program

 

#include "systemc.h"

SC_MODULE(Test) {

  void proc() {
    while (true) {
      cout << sc_time_stamp() << endl;
      wait(10, SC_NS);
    }
  }
 
  SC_CTOR(Test) {
    SC_THREAD(proc);
  }
 
};

int sc_main(int argc, char ** argv) {

  Test t("t");
  sc_start(100, SC_NS);
  return 0;
}
 

 

regards

Alan

 

 

 

 I will try this and let you know Alan. Thanks.

[sonalidutta]

Thank you for replying.

 

Hello,

There should be no confusion about LD_LIBRARY_PATH. It is a Linux runtime

environment variable, to be set right before the simulation is executed. We do

the following on a Fedora 17 machine.

To compile:

g++ -I. -I<absolute or relative path to SystemC 2.3.0 library/include -L.

-L<absolute or relative path to SystemC 2.3.0 library/lib-linux -o

<name of simulation executable> <SystemC executable source file name>

-lsystemc -lm

 

 

If you look at the Makefile in my earlier post I do the same thing.

 

Provided the compilation step does not produce any errors, set the runtime

environment variable, by first finding out the Linux shell being used:

on bash shell:

export LD_LIBRARY_PATH=<absolute or relative path to SystemC 2.3.0 library/lib-linux

Now execute the simulation,

 

 

This is what I do not want to do. Why do I need to export it explicitly? I do not need to do with systems-2.3.0. I only need it with my modified version modified_systemc-2.3.0.

 

All of this is if SELinux is not activated, in which case it has to be de-activated

temporarily(for duration of simulation) in the root/super user mode, by using the

Linux ssyetm command 'setenforce'.

Hope that helps.

[sonalidutta]

Here is my analysis:

 

In you look at systemc-2.3.0/configure:

 

you will see some variables are set in there:

 

PACKAGE=systemc

VERSION=2.3.0

 

And there are many others like this. Search configure file for "systemc" and you will find them.

 

My guess is that these variables are being used to setup default LD_LIBRARY_PATH. Since I have changed the package name from systemc-2.3.0 to modified_systemc-2.3.0, the default path does not work for me anymore. I will run some experiments now to see if I am right.

 

Regards

Sonali

[sonalidutta]

Alan,

 

I changed the name from modified_systemc-2.3.0 to systemc-2.3.0 and reinstalled. But I still has the same issue. As you said I did:

 

ldd addy and here is what I get:

 

[root@localhost adders1]# ldd addy
        linux-vdso.so.1 =>  (0x00007fffefb72000)
        libsystemc-2.3.0.so => not found
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000032b3600000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b666f186000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000032aee00000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b666f409000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b666ef68000)

 

This is my installation path:

 

[root@localhost lib-linux64]# pwd
/root/Desktop/CHIMP_ea/systemc-2.3.0/lib-linux64
[root@localhost lib-linux64]# ls
libsystemc-2.3.0.so  libsystemc.a  libsystemc.la  libsystemc.so
[root@localhost lib-linux64]#
 

As you can see, libsystemc-2.3.0.so exists!
 

[apfitch]

Hi Sonali,

  that's why I said the question is not why does your modified Systemc *not* work, it's why the normal SystemC *does* work!

 

Did you try my "mini" example for both your normal and modified installation?

Did you have a look in /etc/ld.so.conf to see if something was added there?

 

As I said, on my normal system, if I install SystemC under my own user and remove everything from LD_LIBRARY_PATH, I get the same problem you have, so I don't understand why your "standard" install works.

 

One thing I haven't tried is installing as root, in case that lets the install process do something clever that it can't do as a normal user.

 

regards

Alan

[sonalidutta]

Dear Alan,

 

I installed fresh systemc-2.3.0 in /root/Desktop/systemc-2.3.0

 

[root@localhost systemc-2.3.0]# pwd
/root/Desktop/systemc-2.3.0
 

In Desktop I have created hello_world.cpp

 

Now I run:

[root@localhost Desktop]# g++ -I /root/Desktop/systemc2.3.0/include/ -L /root/Desktop/systemc2.3.0/lib-linux64/  -Xlinker -rpath -Xlinker /root/Desktop/systemc2.3.0/lib-linux64/ hello_world.cpp -lsystemc
hello_world.cpp:1:21: error: systemc.h: No such file or directory
hello_world.cpp:3: error: expected constructor, destructor, or type conversion before ‘(’ token
 

Wierd!!!

 

But my adder model is running using it.

 

The thing I observerd that the behavior of systemc-2.3.0 in terms of setting LD_LIBRARY_PATH automnatically is completely unpredictable. Sometimes it does, sometimes it does not.

 

I installed the fresh systemc-2.3.0 1bout 8 times. Only 2 times it did not give the LD_LIBRARY_PATH issue and my systemc model ran fine.

 

So it is not about my modification. As you pointed out correctly, there is some problem in systemc-2.3.0 itself. Can you report a bug?

 

Also I am running as root. So it does not work for root user too!

 

Regarding /etc/ld.so:

 

There is a file called ld.so.conf and a directory callled ld.so.conf.d.

 

But there is no file called ld.so

 

And there is nothing added in any of these file.

 

Thanks

Sonali

[Philipp A Hartmann]

Sonali,

 

So it is not about my modification. As you pointed out correctly, there is some problem in systemc-2.3.0 itself. Can you report a bug?

 

it is not a bug.  SystemC (more precisely libtool, which is used by SystemC 2.3.0) does not set up anything with respect to the dynamic linker paths (which can be modified e.g. by setting the LD_LIBRARY_PATH variable).

 

The current implementation has been tested and is working as expected on a variety of platforms.  Unless you come up with a clear, reproducible demonstration of any misbehaviour, I don't see the issue in the implementation and would suspect your local environment. 

 

In fact, it is expected to configure the linker correctly, also for your modified SystemC library.  During the installation process, libtool explains the situation quite clearly:

 

----------------------------------------------------------------------
Libraries have been installed in:
   ...

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------

 

As you can see, setting LD_LIBRARY_PATH explicitly is one of the expected solutions to resolve the dynamic linking.

 

Greetings from Oldenburg,

  Philipp

[apfitch]

Hi Sonali,

  I didn't mean there's a bug in SystemC 2.3.0 (as Philipp's pointed out above, the behaviour is expected). What I said was

 

"the question is not why does your modified Systemc *not* work, it's why the normal SystemC *does* work!"

 

i.e. what I meant was is that your standard install should *not* work without LD_LIBRARY_PATH (or /etc/ld.so.conf, or -rpath... or whatever).

 

So the mystery is why sometimes your install finds the systemc shared library at run-time and sometimes it doesn't,

 

kind regards

Alan