PLI .so linking, libtool and simulator differences

[Peter Riocreux]

I am trying to develop some PLI code that is portable across platforms
and can be built semi-automagically. Thus I am using libtool to do
this.

I am linking together 7 libtool-generated libraries, another
that is causing problems and an automagically generated C file.

My problem is that the resultant .so file works happily with verilog
XL and NCverilog, but VCS barfs on it during its link phase. (This is
on a Solaris 8 or 9 platform with VCS version 6.0.1)

The messages VCS gives are:

Undefined first referenced
symbol in file
BalsaSimBuiltinFunction_check /tmp/v101905NrIB_d.o
(symbol belongs to implicit dependency /tmp/balsa-3.4/lib/libbalsasimverilog.so.0)
tf_setworkarea /tmp/balsa-3.4/lib/libbalsasimverilog.so.0
tf_getworkarea /tmp/balsa-3.4/lib/libbalsasimverilog.so.0
BalsaSimBuiltinFunction_call /tmp/v101905NrIB_d.o
(symbol belongs to implicit dependency /tmp/balsa-3.4/lib/libbalsasimverilog.so.0)
tf_message /tmp/balsa-3.4/lib/libbalsasimverilog.so.0
tf_nump /tmp/balsa-3.4/lib/libbalsasimverilog.so.0
ld: fatal: Symbol referencing errors. No output written to simv

At first glance this looks like the problem file
(libbalsasimverilog.so.0) has not been linked in properly, but that is
the only file that uses the tf_* routines, so it is discovering it
needs them. So it *is* linking in that file and it appears to be
linking that file to the others as functions provided by the 7 other
libs appear to be resolved as far as the problem one goes. In fact it
seems that the *only* symbols remaining unresolved are things that
cross the problem library/vcs boundary. But it is not all of them, as
the _check and _call functions also use acc_* functions.

$nm -g /tmp/balsa-3.4/lib/libbalsasimverilog.so.0 gives, amongst other
stuff:

[79] | 4200| 912|FUNC |GLOB |0 |8 |BalsaSimBuiltinFunction_call
[54] | 2420| 1708|FUNC |GLOB |0 |8 |BalsaSimBuiltinFunction_check

So the symbols are there and have some code behind them.

To confuse matters further, if I specify the problem library also on
the command line, the link stage works fine, whether or not I include
the problem library in my big, combined one.

The problem library itself is built using an automake libtool rule, as
are three of the non-problem libraries, so I have some difficulty
believing it is anything special about the problem library itself. The
final, all linked together thing is built using a script that invokes
libtool in the various modes.

The relevant lines from what libtool does in the final stage are:

gcc -c -I/home/amulocal/solaris/include -I/home/amulocal/common/include foo.c -fPIC -DPIC -o foo.lo
ld -G -h foo.so.0 -o foo.so.0.0.0 foo.lo -R/tmp/balsa-3.4/lib .......[deleted bunch of libs]

foo.c is the test, automagically generated file.

Does anyone have any idea what the cause of my problem is?

I can generate enormous amounts of info if it will help anyone.

Peter

--
Peter Riocreux, Amulet Group, Dept. Computer Science, Manchester University,
Oxford Road, MANCHESTER, M13 9PL, UK. <http://www.cs.man.ac.uk/apt/>

 

[Swapnajit Mittra]

Peter Riocreux <priocreux@cs.man.ac.uk> wrote in message news:<9k3cfnnxo0.fsf@cs.man.ac.uk>...

I am trying to develop some PLI code that is portable across platforms
and can be built semi-automagically. Thus I am using libtool to do
this.

I am linking together 7 libtool-generated libraries, another
that is causing problems and an automagically generated C file.

My problem is that the resultant .so file works happily with verilog
XL and NCverilog, but VCS barfs on it during its link phase. (This is
on a Solaris 8 or 9 platform with VCS version 6.0.1)

[...]
Does anyone have any idea what the cause of my problem is?

I can generate enormous amounts of info if it will help anyone.

Peter

To ask the obvious: have you correctly #include-ing vcsuser.h?
Is the include path correctly being specified as -I in the
csrc/Makefile?

- Swapnajit.

=-=-= 100% pure Verilog PLI - go, get it ! =-=-=
Principles of Verilog PLI -By- Swapnajit Mittra
Kluwer Academic Publishers. ISBN: 0-7923-8477-6
http://www.angelfire.com/ca/verilog/

 

[Peter Riocreux]

"SM" == Swapnajit Mittra <mittra@juno.com> writes:

SM> Peter Riocreux <priocreux@cs.man.ac.uk> wrote in message
SM> news:<9k3cfnnxo0.fsf@cs.man.ac.uk>...

I am trying to develop some PLI code that is portable across
platforms and can be built semi-automagically. Thus I am using
libtool to do this.

I am linking together 7 libtool-generated libraries, another that
is causing problems and an automagically generated C file.

My problem is that the resultant .so file works happily with
verilog XL and NCverilog, but VCS barfs on it during its link
phase. (This is on a Solaris 8 or 9 platform with VCS version
6.0.1)

SM> [...]
Does anyone have any idea what the cause of my problem is?

I can generate enormous amounts of info if it will help anyone.

Peter

SM> To ask the obvious: have you correctly #include-ing vcsuser.h? Is
SM> the include path correctly being specified as -I in the
SM> csrc/Makefile?

I am not letting VCS compile *any* part of my .so - it is all done by
libtool. All the various bits of my .so are linked together using
libtool, so I only have one non-verilog file on the command line, and
that is the .so. So it is nothing to do wih including headers as all
compilation is long done by the time VCS gets hold of it.

Peter

--
Peter Riocreux, Amulet Group, Dept. Computer Science, Manchester University,
Oxford Road, MANCHESTER, M13 9PL, UK. <http://www.cs.man.ac.uk/apt/>

 

[Peter Riocreux]

"P" == Prasanna <pra_verilog@yahoo.com> writes:

P> Peter Riocreux <priocreux@cs.man.ac.uk> wrote in message
P> news:<9k3cfnnxo0.fsf@cs.man.ac.uk>...

I am trying to develop some PLI code that is portable across
platforms and can be built semi-automagically. Thus I am using
libtool to do this.

I am linking together 7 libtool-generated libraries, another that
is causing problems and an automagically generated C file.

My problem is that the resultant .so file works happily with
verilog XL and NCverilog, but VCS barfs on it during its link
phase. (This is on a Solaris 8 or 9 platform with VCS version
6.0.1)

The messages VCS gives are:

Undefined first referenced symbol in file
BalsaSimBuiltinFunction_check /tmp/v101905NrIB_d.o (symbol belongs
to implicit dependency /tmp/balsa-3.4/lib/libbalsasimverilog.so.0)
tf_setworkarea /tmp/balsa-3.4/lib/libbalsasimverilog.so.0
tf_getworkarea /tmp/balsa-3.4/lib/libbalsasimverilog.so.0
BalsaSimBuiltinFunction_call /tmp/v101905NrIB_d.o (symbol belongs
to implicit dependency /tmp/balsa-3.4/lib/libbalsasimverilog.so.0)
tf_message /tmp/balsa-3.4/lib/libbalsasimverilog.so.0 tf_nump
/tmp/balsa-3.4/lib/libbalsasimverilog.so.0 ld: fatal: Symbol
referencing errors. No output written to simv

At first glance this looks like the problem file
(libbalsasimverilog.so.0) has not been linked in properly, but that
is the only file that uses the tf_* routines, so it is discovering
it needs them. So it *is* linking in that file and it appears to be
linking that file to the others as functions provided by the 7
other libs appear to be resolved as far as the problem one goes. In
fact it seems that the *only* symbols remaining unresolved are
things that cross the problem library/vcs boundary. But it is not
all of them, as the _check and _call functions also use acc_*
functions.

$nm -g /tmp/balsa-3.4/lib/libbalsasimverilog.so.0 gives, amongst
other stuff:

[79] | 4200| 912|FUNC |GLOB |0 |8 |BalsaSimBuiltinFunction_call
[54] | 2420| 1708|FUNC |GLOB |0 |8 |BalsaSimBuiltinFunction_check

So the symbols are there and have some code behind them.

To confuse matters further, if I specify the problem library also
on the command line, the link stage works fine, whether or not I
include the problem library in my big, combined one.

The problem library itself is built using an automake libtool rule,
as are three of the non-problem libraries, so I have some
difficulty believing it is anything special about the problem
library itself. The final, all linked together thing is built using
a script that invokes libtool in the various modes.

The relevant lines from what libtool does in the final stage are:

gcc -c -I/home/amulocal/solaris/include
-I/home/amulocal/common/include foo.c -fPIC -DPIC -o foo.lo ld -G
-h foo.so.0 -o foo.so.0.0.0 foo.lo -R/tmp/balsa-3.4/lib
.......[deleted bunch of libs]

foo.c is the test, automagically generated file.

Does anyone have any idea what the cause of my problem is?

I can generate enormous amounts of info if it will help anyone.

Peter

P> Hi Peter,

P> I can suggest following debug procedures only.

P> 1. Check if your verilog-xl or ncverilog binary with "strings"
P> command
P> for existence of the $<pli_call>. If it exists your verilog-xl and
P> ncverilog are good. Only VCS has the problem (confirmed !!!)

But I already know that XL and NC work - they simulate correctly.

I cannot run strings on the VCS binary because there is none, because
the link stage chokes.

P> 2. On VCS, replace the function calls with dummy function calls
P> using
P> io_printf that just displays name of the function called. Compile
P> and link and check if you still get error messages. Sometimes "nm
P> -r <lib_name> provides warning stating that <lib_name> is not up to
P> date and use "ar" command to fix it. Check for all other warnings
P> during compilation.

I have discovered that I can fix it by linking against a static
version of the lib in question, so the problem is that VCS seems not
to be able to link to symbols dynamically linked from something that
VCS links against - i.e. it cannot manage more than a single
indirection.

I am no clearer on why VCS cannot do this but NC and XL can, but ....

Peter

--
Peter Riocreux, Amulet Group, Dept. Computer Science, Manchester University,
Oxford Road, MANCHESTER, M13 9PL, UK. <http://www.cs.man.ac.uk/apt/>

 

[Petter Gustad]

Peter Riocreux <priocreux@cs.man.ac.uk> writes:

I am not letting VCS compile *any* part of my .so - it is all done by
libtool. All the various bits of my .so are linked together using

What options are you passing to VCS, e.g. order of -l options as well
as the -LDFLAGS options you are using?

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Peter Riocreux]

"PG" == Petter Gustad <newsmailcomp5@gustad.com> writes:

PG> Peter Riocreux <priocreux@cs.man.ac.uk> writes:

I am not letting VCS compile *any* part of my .so - it is all done
by libtool. All the various bits of my .so are linked together
using

PG> What options are you passing to VCS, e.g. order of -l options as
PG> well as the -LDFLAGS options you are using?

No options at all apart from the -R to run the resultant binary and -P
to pick up the PLI table file.

Peter

--
Peter Riocreux, Amulet Group, Dept. Computer Science, Manchester University,
Oxford Road, MANCHESTER, M13 9PL, UK. <http://www.cs.man.ac.uk/apt/>
Voice: +44 161-2753547 Mobile: +44 7970-611366 Fax: +44 161-2756236

 

[Petter Gustad]

Peter Riocreux <priocreux@cs.man.ac.uk> writes:

"PG" == Petter Gustad <newsmailcomp5@gustad.com> writes:

PG> Peter Riocreux <priocreux@cs.man.ac.uk> writes:
I am not letting VCS compile *any* part of my .so - it is all done
by libtool. All the various bits of my .so are linked together
using

PG> What options are you passing to VCS, e.g. order of -l options as
PG> well as the -LDFLAGS options you are using?

No options at all apart from the -R to run the resultant binary and -P
to pick up the PLI table file.

So you only specify the path to your libraries on the vcs command
line?

Have you tried to do something like:

vcs ... -LDFLAGS "-L/path/to/my/lib -R/path/to/my/lib -lmy"

The -R option depends upon which C compiler you use (typically gcc or
the Sun WorkShop Compiler).

Linking vcs is not any different from linking any other program so you
might have dependencies which require you to specify a library twice.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Peter Riocreux]

"PG" == Petter Gustad <newsmailcomp5@gustad.com> writes:

PG> Peter Riocreux <priocreux@cs.man.ac.uk> writes:

"PG" == Petter Gustad <newsmailcomp5@gustad.com> writes:

PG> Peter Riocreux <priocreux@cs.man.ac.uk> writes:
I am not letting VCS compile *any* part of my .so - it is all
done by libtool. All the various bits of my .so are linked
together using

PG> What options are you passing to VCS, e.g. order of -l options as

PG> well as the -LDFLAGS options you are using?

No options at all apart from the -R to run the resultant binary and
-P to pick up the PLI table file.

PG> So you only specify the path to your libraries on the vcs command
PG> line?

PG> Have you tried to do something like:

PG> vcs ... -LDFLAGS "-L/path/to/my/lib -R/path/to/my/lib -lmy"

PG> The -R option depends upon which C compiler you use (typically gcc
PG> or the Sun WorkShop Compiler).

PG> Linking vcs is not any different from linking any other program so
PG> you might have dependencies which require you to specify a library
PG> twice.

But it *is* resolving some of the function calls from the problem
library, just not others. Specifically is manages to resolve all the
acc_* calls but not the tf_* calls. It also doesn't manage to resolve
the calls to the (user) functions that *call* the tf_* calls. As it
complains about not resolving the tf_* calls, it must be loading the
library, but then it *should also complain about the acc_* calls if it
were a *simple* linking problem. As it is, the *partial* linking is
what is mystifying me.

I think I need to pare it down and create an example to demonstrate
this as I don't think the full weirdness is apparent to people.

Tahnks for your thoughts though.

Peter

--
Peter Riocreux, Amulet Group, Dept. Computer Science, Manchester University,
Oxford Road, MANCHESTER, M13 9PL, UK. <http://www.cs.man.ac.uk/apt/>