Accroding to IQ' udf guide,
create udf procedure as below:
Declare the UDF to the server by using the CREATE FUNCTION or CREATE AGGREGATE FUNCTION
Write the UDF library identification function
Define the UDF as a set of C or C++ functions.
Implement the function entry points in C/C++.
Compile the UDF functions and the library identification functions
Link the compiled file into a dynamically linkable library.
After I alreary done the all procedure, and Declare CREATE FUNCTION in Interactice SQL, I call function and got error response as below:
`
Could not execute statement.
Could not find 'my_sample_function' in dynamic library 'libudfex.so'
SQLCODE=-621, ODBC 3 State="HY000" Line 1, column 1 SELECT
my_sample_function(test.a, test.b) as aaa FROM test WHERE test.a = 3
`
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01034.1520/doc/html/jfo1254246965959.html
After the dynamically linkable library has been compiled and linked, complete one of these tasks:
1.(Recommended) update the CREATE FUNCTION ... EXTERNAL NAME to include an explicit path name for the UDF library.
Place the UDF library file into the directory where all the IQ libraries are stored.
2.Start the IQ server with a library load path that includes the location of the UDF library.
3.On UNIX modify the LD_LIBRARY_PATH within the start_iq startup script. While LD_LIBRARY_PATH is universal to all UNIX variants, SHLIB_PATH is preferred on HP, and LIB_PATH is preferred on AIX.
Maybe you miss this step
Related
I need to use an externally built C library doing some calculation with trigonometric services to my Ada program. I do it well using an stm32 bb runtime (SFP) but when trying to do the same in a native environment using the default Ada runtime, I end up with linking problems. Hope I can find some help here.
I tried several configurations of project files (gpr) solutions and I always end up with the same kind of linking error:
Memory region Used Size Region Size %age Used/opt/gnat/gnat_native/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.3.1/ld: /home/pulsar/repos/pulsar-software/something/lib_c/libC.a(something.o): in function `compute':
(.text+0xa5): undefined reference to `sin'
collect2: error: ld returned 1 exit status
Here is what I've got so far.
The C library build sequence is as follows (confirmed by the library provider):
$ gcc -c something.c -o something.o
$ ar -r libsomethingLib.a something.o
The C library gpr file something_lib_c.gpr:
library project Something_Lib_C is
for Languages use ("C");
for Externally_Built use "true";
for Source_Dirs use ("src_c");
for Library_Dir use "lib_c";
for Library_Name use "somethingLib";
for Library_Kind use "static";
end Geocaging_Lib_C;
In the lib_c directory, I have the actual library libsomethingLib.a
In the src_c directory, I have the header API to use the C library (something.h):
#ifndef _GEOCAGING_H
#define _GEOCAGING_H
typedef struct something_s something_t;
extern void compute(something_t* const self);
#endif // _GEOCAGING_H
Then here is the Ada project file that wraps the C library something_lib.gpr:
with "something_lib_c.gpr";
project Something_Lib extends "../settings.gpr" is
for Languages use ("Ada");
for Source_Dirs use ("./src_ada");
for Object_Dir use "obj" & "/" & Target & "/" & Build;
end Geocaging_Lib;
In the directory src_ada, I have the Ada API wrapper (something_api.ads):
with Interfaces; use Interfaces;
with Interfaces.C; use Interfaces.C;
package Something_API is
type T_Something is null record;
procedure Compute (Something : access T_Something);
with Import => True,
Convention => C,
External_Name => "compute";
end Something_API;
And finally, I call the compute service from my Ada program by with-ing the Ada API wrapper.
Once again, when building/linking the whole thing for an arm-eabi target, using an stm32-full or stm32-sfp Ada runtime, everything runs well and the behavior of the library is validated.
The whole point is I'd like to do the thing in a native environment in order to run CI tests on it and I can't find a way to pass the link stage.
Last thing, in the Settings.gpr generic project file contains some common Ada build/bind/build switches that I can provide if necessary. But I can't see how this could work in arm and not in native with the same options. This HAS to be linked to the default Ada runtime thing...
Any idea?
If you were building with a C main program, what would you have to do to bring in the maths libraries at link time? ... possibly something like
gcc foo.c -l somethingLib -lm
What you need to do is to arrange for the -lm to be included whenever you call in something_lib_c.gpr.
I think that what you need to do is to modify library project Something_Lib_C to include the line
for Library_Options use ("-lm");
OK, my HUGE apologies to all of you who tried to help...
The solution was more obvious than I thought, I was just too obsessed with the thing working in arm and not in native.
BUT, the solution was simply to add the -lm switch to the global linker switches. Hence:
Ada_Switches_Linker_Native := (
"-Wl,--gc-sections"
,"-Wl,--verbose"
,"-Wl,-lm"
);
package Linker is
case Target is
when "native" =>
for Switches ("Ada") use Ada_Switches_Linker_Native;
...
end case;
end Linker;
In case it could be of interest for someone else, the fact that it works straightforward in arm environment and not in native is because the default runtime does not embed a specific mathematical library and you are supposed to use the C one provided by gcc, linking through the -lm switch.
In the contrary, when using a target specific runtime like arm (for stm32f4 for example), the correct mathematical libraries are provided, selected and automatically linked depending on your compilation options (-mhard-float, -msoft-float, etc.).
Sorry again and thank you very much for your time.
I want to build a .so library using Go/Cgo with options go build -buildmode=c-shared.
Functions exports well, but I cannot export variables. I need to realize an API, which works by calling a void function, which sets up values of various global properties. Something like this:
var (
Gval1 int
Gval2 string
//GvalN
)
func f(){
Gval1 = 1
Gval2 = "qwerty"
}
The client of .so lib will run f(); and after that, it can get variables by addressing their names. How can I export them?
I had tried to do a trick like this: golang cgo can't export variables by build mode c-shared, but there was no success (example returns always 0, not 42).
How can I export variables (numbers and strings)?
I don't think you can export variables, only functions.
The go build documentation says:
-buildmode=c-shared
Build the listed main package, plus all packages it imports,
into a C shared library. The only callable symbols will
be those functions exported using a cgo //export comment.
Requires exactly one main package to be listed
Where the cgo docs says
Go functions can be exported for use by C code in the following way:
I guess you can write a function that returns the variable value.
What is the proper way to load in a dynamically linked library (i.e., a .so file) when writing an R package? The only solution that has worked for me so far has been to specify the full path to the .so file, e.g.:
dyn.load('/FULL/PATH/TO/MY/R_PACKAGE/src/my_file.so')
Obviously, this approach will not work for a CRAN/Bioconductor submission since the .so file will not be located. As such, I have (unsuccessfully) tried the following alternatives:
1) library.dynam()
2) library.dynam('my_file.so')
3) library.dynam('my_file.so', 'R_PACKAGE')
4) system.file("src", "my_file.so", package = "R_PACKAGE")
Related links: R: C symbol not in load table, R: C symbol name not in load table - error in linking with external .c files.
Just to be crystal clear, users of my R package may obviously set any arbitrary working directory on their computers. The only way a full path approach (as shown above) would ever work is if they set their working directory to /FULL/PATH/TO/MY/R_PACKAGE/src, which is (of course) impractical.
The standard way to do this, as described in Writing R Extensions, is:
1.5.4 useDynLib
A NAMESPACE file can contain one or more useDynLib directives which allows shared objects that need to be loaded.* The directive
useDynLib(foo)
registers the shared object foo** for loading with library.dynam. Loading of registered object(s) occurs after the package code has been loaded and before running the load hook function. Packages that would only need a load hook function to load a shared object can use the useDynLib directive instead.
* NB: this will only be read in all versions of R if the package contains R code in a R directory.
** Note that this is the basename of the shared object, and the appropriate extension (.so or .dll) will be added.
Quick points:
Why do you need to ship a .so file? This would preclude uploads to common repos like CRAN which will not accept binary content
You can compute the full /FULL/PATH/TO/MY/R_PACKAGE/src/my_file.so by using system.file("src", "my_file.so", package="R_PACKAGE") (but then make sure you actually install a src/ which is not standard)
In all other cases (as pointed out by #BenBolker) R will know how to create the dynamic library and load it for you. Every package with compiled code does that. Just drop your source code into src/ and you are (essentially) done.
The point is to generate a hex without main function using IAR linker - xlink?
This code should be loaded into the RAM of RL78 MCU.
A quick Google search of iar generate hex from library brought me to this document, "Creating an Absolutely Placed Library", as a first result. It has all the information you need, plus some information on using a CRC for consistency checking. The document is for the IAR EWRX variant, but the concepts should all be the same.
The basic process is to compile your library as an executable, but without a main() function in it. You'll need to set your library configuration under General -> Library Options to None. You can also setup your file conversion settings at this point.
Since you don't have a main() function for a program entry point, you will need to create an entry function to call the IAR C runtime initialization function, __iar_data_init2(), and then set the linker to use this function as the entry point (which can be found under Linker Options -> Library Options).
When building a library, all the symbols will be preserved until the final link step for the application using it, but since you are building this as an executable, it is important that the symbols you want to keep have the __root keyword, or under Linker -> Extra Options you can specify --no-remove to keep all symbols.
In the next step, you need to use isymexport to export the symbols that you want. You will need a file to direct the tool what to export. In the example, they have a file that just contains the following:
show lib_*
show __checksum*
This will direct the tool to export all symbols beginning with lib_ and all symbols beginning with __checksum. They note that __iar_data_init2() should not be exported, as this would cause conflicts with the application that ultimately will use this code. You invoke the tool like so:
isymexport <path to .out file> <path to output from tool> --edit <path to file created above>
Now you should have the output from isymexport and the library file that you were looking for. For the application using this library, you'll need to add the output from isymexport as a library under Linker -> Library, and in your application, you'll need to call your entry function in the library before you attempt to use any of the library's symbols.
This should be the information you need to generate a library that lives in a hex file and can be loaded separately, as well as how to use that library. The referenced document has a lot more detail, so if it is available at that link (or can be found elsewhere by title) it will be a better reference than my summary here.
We have a legacy library implementation and associated exposed header files. Recently we found that, some of the functions in the exposed header file, don't have corresponding definitions in the library implementation.
We want to check if there could be some more such functions. Is there any easier way of doing this rather than sifting through each and every API present in header and then checking if there is a definition for it?
You can generate C source from the header (Perl is a way to go!) that calls all the functions and try to compile it. Linker will complain about missing functions.
Try to create the ABI dump file by the abi-compliance-checker tool:
abi-compliance-checker -lib NAME -dump DESC.xml
DESC.xml file is the following:
<version>
1.0
</version>
<headers>
/path(s)/to/headers
</headers>
<libs>
/path(s)/to/libraries
</libs>
The resulting ABI dump file will contain the information you need about symbols declared in header files (SymbolInfo) and symbols exported by shared libraries (Symbols).
You can also generate ABI dump in the xml format by adding --xml option.
If this is C, you can do something like:
printf("", /* insert all functions here */);
That should pass them all as function pointers to printf. The ones that do not exist should show up as linker errors.
(In C++, you would have to list overloads explicitly, which makes it a bit more difficult.)
I'd be inclined to use ctags to generate a list of identifiers from the header file then use ar, emfar or elfdump in Unix or lib.exe or dumpbin.exe in Windows (see discussion here) to dump a list of identifiers from the library and then sort and diff the two lists.