Re: Embedding problems with DynaLoader on Solaris
Nick Ing-Simmons wrote: The compile and link lines look like this: gcc -c -fPIC -DPRO_MACHINE=19 -DPRO_OS=3 -DSOLARIS -I. -Iincludes -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/perl/lib/5.6.1/sun4-solaris/CORE properl.c ld -G -Bsymbolic -o properl.dll properl.o ./protk_dll.a /usr/perl/lib/5.6.1/sun4-solaris/auto/DynaLoader/DynaLoader.a -L/usr/perl/lib/5.6.1/sun4-solaris/CORE -lperl -L/opt/gcc-2.95.3/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3 -lgcc -lsocket -lnsl -lw -lm -ldl -lc The link step (using ld) is modified by setting '-G -Bsymbolic', then linking in the cad api library (protk_dll.a), 'libgcc' (probably should just use gcc for linking), and 'libw'. Can you try without the -Bsymbolic ? Or explain why you need it (I don't have a Solaris machine anymore so I can't look it up - and Linux man pages are unreliable for Solaris features! they are similar but not exactly the same.) Without -Bsymbolic, the app cannot be loaded at runtime. It is an option used by example makefiles with this CAD api, and it seems that I cannot remove it. From solaris 'ld' man page: -B symbolic In dynamic mode only. When building a shared object, binds references to global symbols to their defini- tions, if available, within the object. Normally, references to global symbols within shared objects are not bound until runtime, even if definitions are available, so that definitions of the same symbol in an executable or other shared object can override the object's own definition. ld will issue warnings for undefined symbols unless -z defs overrides. -GIn dynamic mode only, produces a shared object. Unde- fined symbols are allowed. I am using gcc built on Solaris 2.6, but linking and running the app on Solaris 8. Could that be causing some issues? Marc -- Marc Mettes CAD Support Bic Corporation
Re: Embedding problems with DynaLoader on Solaris
Marc Mettes wrote: I'm working on a project embedding and extending perl into a CAD API. The API allows for an external executable that communicates through an RPC mechanism, or a shared library loaded dynamically. The choice is made at link time by the selection of the appropriate library. I've had great success on Solaris8/gcc with the external executable using a statically built perl and everything runs as expected. The shared library method using the same perl has caused some problems when using C based perl modules. When using this 'go.pl': use Data::Dumper; print hello world, \n; I get the following error message: Can't load '/usr/perl/lib/5.6.1/sun4-solaris/auto/Data/Dumper/Dumper.so' for module Data::Dumper: ld.so.1: /opt/pro/sun4_solaris/obj/pro: fatal: relocation error: file /usr/perl/lib/5.6.1/sun4-solaris/auto/Data/Dumper/Dumper.so: symbol main: referenced symbol not found at /usr/perl/lib/5.6.1/sun4-solaris/XSLoader.pm line 75. at /usr/perl/lib/5.6.1/sun4-solaris/Data/Dumper.pm line 27 Compilation failed in require at go.pl line 5. BEGIN failed--compilation aborted at go.pl line 5. With just the print statement, the script runs just fine. Can someone give me some suggestions on resolving this problem? The error complains about a 'main', but which 'main' is it talking about? In this situation, I don't have a main(). The main() is in the CAD executable, which loads my shared library and excutes my user_initialize(). Marc -- Marc Mettes CAD Support Bic Corporation
Re: getenv() problems
Good point, thanks. I did send in a 0, which behaved better.
But the env still didn't get read, but I didn't investigate that
much. I resorted to putting a object frontend, and having the
object handle the env OpenLog, so actuall values are always
sent as arguments.
On 03-Jun-2003 Nick Ing-Simmons wrote:
[EMAIL PROTECTED] writes:
..The problem is that the c function is not getting the vars from
the env, when running under Perl. The getenv() does not seem to
work. If I set the variables $ENV{PROJECT} = and $ENV{SERVICE} = 1,
call the function OpenLog(Arg, Arg, , ), the function will see the
2 empty strings and attemt to read the values from the env. These env
variables could be set by a shell script before the perl is run. The perl
code could be last in a series of utilities that use these env vars. It works
if the actual arguments are sent to the function, but I would like to have
the interface behave as the C calls do. Here is some of the C code if my
explaination is to vague,
DotsLog.Project = GETENV(inproject, PROJECTNUM);
#define GETENV(var, env) ( (var) == NULL ? getenv((env)) : (var) )
But you are not passing NULL you are passing
NULL is (char *) 0
is pointer to a byte containing '\0'.
You may need a custom typemap to cause (or better undef)
to be passed to your library as NULL.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
--
E-Mail: [EMAIL PROTECTED]
Date: 03-Jun-2003
Time: 14:00:12
--
Re: Embedding problems with DynaLoader on Solaris
Marc Mettes [EMAIL PROTECTED] writes: Nick Ing-Simmons wrote: The compile and link lines look like this: gcc -c -fPIC -DPRO_MACHINE=19 -DPRO_OS=3 -DSOLARIS -I. -Iincludes -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/perl/lib/5.6.1/sun4-solaris/CORE properl.c ld -G -Bsymbolic -o properl.dll properl.o ./protk_dll.a /usr/perl/lib/5.6.1/sun4-solaris/auto/DynaLoader/DynaLoader.a -L/usr/perl/lib/5.6.1/sun4-solaris/CORE -lperl -L/opt/gcc-2.95.3/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3 -lgcc -lsocket -lnsl -lw -lm -ldl -lc Can you try without the -Bsymbolic ? Without -Bsymbolic, the app cannot be loaded at runtime. It is an option used by example makefiles with this CAD api, and it seems that I cannot remove it. But you can turn it off for some libraries. Without a Solaris machine to test it on I cannot be sure but I am reasonably certain that -Bsymbolic binding of -ldl renders it useless (the same may be true of -lnsl IIRC). Try re-enabling dynamic binding for -ldl and -lc ld -G -Bsymbolic -o properl.dll properl.o ./protk_dll.a /usr/perl/lib/5.6.1/sun4-solaris/auto/DynaLoader/DynaLoader.a -L/usr/perl/lib/5.6.1/sun4-solaris/CORE -lperl -L/opt/gcc-2.95.3/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3 -lgcc -lsocket -lnsl -lw -lm -Bdynamic -ldl -lc Or perhaps just the problem library: ld -G -Bsymbolic -o properl.dll properl.o ./protk_dll.a -Bdynamic /usr/perl/lib/5.6.1/sun4-solaris/auto/DynaLoader/DynaLoader.a -L/usr/perl/lib/5.6.1/sun4-solaris/CORE -lperl -L/opt/gcc-2.95.3/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3 -lgcc -lsocket -lnsl -lw -lm -ldl -lc -B symbolic In dynamic mode only. When building a shared object, binds references to global symbols to their defini- tions, if available, within the object. Normally, references to global symbols within shared objects are not bound until runtime, even if definitions are available, so that definitions of the same symbol in an executable or other shared object can override the object's own definition. ld will issue warnings for undefined symbols unless -z defs overrides. That would also imply that code is going to define symbols which conflict with root executable. This is going to be a problem because the way perl dynamic loading works relies on symbols from -lperl being available to loaded perl extensions. We have not got that far yet, but when you do you are going to have to use one of the dlopen() tricks discussed on this list recently, to make perl's symbols available and that will make these must-be-symbolic symbols visible too. I am using gcc built on Solaris 2.6, but linking and running the app on Solaris 8. Could that be causing some issues? I think gcc-2.8+ is much better at this that earlier ones but it could be causing problems. Marc -- Nick Ing-Simmons http://www.ni-s.u-net.com/
