gpibtcl: unresolved symbol: _Z... while loading *.so

[wiede...@googlemail.com]

Hi,

to use the ethernet based GPIB inteface box we have,
I have tried to rebuild libgpibtcl.so ( which produces a *.so )
during package require the load of libgpibtcl.so breaks with

couldn't load file "./libgpibtcl.so": ./libgpibtcl.so: undefined
symbol: _Z5ibdeviiiiii

( "ibdev" is from the basic nonc++ libgpibenet.so provided by NI,
local apps work quite well with this)

which seems to be an issue with name mangling in c++.

I have always been a good boy and kept my fingers off c++
so I am absolutely stumped here.

Any good hints how to resolve this?

System is SuSE 9.3, linux 2.4.20 gcc 3.3 20030226 tcl 8.4.2, no stubs
( I know it is old, there are more conservative souls around than one
might think ;- )

G!
uwe

[Christian Gollwitzer]

wiede...@googlemail.com schrieb:

> to use the ethernet based GPIB inteface box we have,
> I have tried to rebuild libgpibtcl.so ( which produces a *.so )
> during package require the load of libgpibtcl.so breaks with
>
> couldn't load file "./libgpibtcl.so": ./libgpibtcl.so: undefined
> symbol: _Z5ibdeviiiiii
>
> ( "ibdev" is from the basic nonc++ libgpibenet.so provided by NI,
> local apps work quite well with this)
>
> which seems to be an issue with name mangling in c++.

it seems, that during compilation of libgpibtcl.so the NI headers are
included as C++ files. You should look for

#include "ni488.h"

and change it to e.g.

extern "C" {
#include "ni488.h"
}

BTW, my ni488.h does the extern "C" stuff by itself. Is it possible,
that your NI SDK is rather ancient or that instead, "decl32.h" is
included, which is the old one?

BTW2, I've enroled my own GPIB library using SWIG with an OO-interface.
It also includes Tcl-level callbacks for service requests. An example
program for handling service requests to measure temperatures with a
PREMA multimeter looks like this:

load "gpibsrq.dll"

proc pause { ms } {
after $ms { set _ 0 }
vwait _
}

proc readvalue {spoll} {
set temp [prema query "RD?" ]
puts "got new value: [expr {$temp}]°C"
}

gpibdevice prema 22
prema write "TC A0 F0 T5 Q1 L0"
# setup for measuring the temperature
prema write "*SRE1"
# enable SRQ on new measurements

puts [prema query "*SRE?"]

pause 1000
prema srq {readvalue %s}
# callback function for SRQs
pause 5000

prema stopsrq

If you are interested, I can send you the source code

Christian

[wiede...@googlemail.com]

Hi Christian,
thanks a lot for your answer. this works.
On May 15, 7:31 pm, Christian Gollwitzer <Christian.Gollwit...@uni-
bayreuth.de> wrote:
> wiederl...@googlemail.com schrieb:

>
> > to use the ethernet based GPIB inteface box we have,
> > I have tried to rebuild libgpibtcl.so ( which produces a *.so )
> > during package require the load of libgpibtcl.so breaks with
>
> > couldn't load file "./libgpibtcl.so": ./libgpibtcl.so: undefined
> > symbol: _Z5ibdeviiiiii
>
> > ( "ibdev" is from the basic nonc++ libgpibenet.so provided by NI,
> > local apps work quite well with this)
>
> > which seems to be an issue with name mangling in c++.
>
> it seems, that during compilation of libgpibtcl.so the NI headers are
> included as C++ files. You should look for
>
> #include "ni488.h"
>
> and change it to e.g.
>
> extern "C" {
> #include "ni488.h"
>
> }

the 'extern "C"' made the difference
though I have to include <sys/ugpib.h>

>
> BTW, my ni488.h does the extern "C" stuff by itself. Is it possible,
> that your NI SDK is rather ancient or that instead, "decl32.h" is
> included, which is the old one?

NO idear. the provided *.h file has
Copyright (c) 1994 National Instruments Corp.
The box I am working on for this is well matured. The person
who created the testsetup is very comfortable with C. So
every programm that does some instrument control is compiled
c. ( which makes even changing addresses or start values a hassle )

>
> BTW2, I've enroled my own GPIB library using SWIG with an OO-interface.
> It also includes Tcl-level callbacks for service requests. An example
> program for handling service requests to measure temperatures with a
> PREMA multimeter looks like this:
>
> load "gpibsrq.dll"
>
> proc pause { ms } {
>    after $ms { set _ 0 }
>    vwait _
>
> }
>
> proc readvalue {spoll} {
>    set temp [prema query "RD?" ]
>    puts "got new value: [expr {$temp}]°C"
>
> }
>
> gpibdevice prema 22
> prema write "TC A0 F0 T5 Q1 L0"
> # setup for measuring the temperature
> prema write "*SRE1"
> # enable SRQ on new measurements
>
> puts [prema query "*SRE?"]
>
> pause 1000
> prema srq {readvalue %s}
> # callback function for SRQs
> pause 5000
>
> prema stopsrq
>
> If you are interested, I can send you the source code
>
>         Christian

I would be very interested! my mailaddress is valid.

G!
uwe

[Derek Philip]

Hi

Not a tcl reply but..

I work in a lab full of test equipment, scopes, spectrum analysers,
power supplies, meters, etc..., we very rareley use the provided GPIB
port, preferring the serial or LAN for our SCPI connections.

It removes a layer of S/W and its maintenance along with a source of
errors thus, in theroy at least, better robustness.

Derek

[Uwe Klein]

Derek Philip wrote:
> Hi
>
> Not a tcl reply but..
>
> I work in a lab full of test equipment, scopes, spectrum analysers,
> power supplies, meters, etc..., we very rareley use the provided GPIB
> port, preferring the serial or LAN for our SCPI connections.
>
> It removes a layer of S/W and its maintenance along with a source of
> errors thus, in theroy at least, better robustness.

Hi Derek,
I have looked into that for the newer LeCroy DSOs we have here.
But most of the instrumentation I have access to speaks GPIB only.
( Lots of Rohde & Schwarz Boxes from the 90ties ;-)

uwe