Post by Luis SilvaHi,
How can I Bind a library when cimpiling with CCOMP?
I might be missing something so simple but I can't find it. Hope you can point me in the right direction.
I have one runnable program and another with sobre functionality.
I can compile each of them with no problem.
ccomp /in <myin> /<myout>; runnable, extensions
It works, it executes, ok.
ccomp /in <myin> , lib <mylib> /<myout>; runnable, extensions
I get an Illegal library file format.
<mylib> was compiled
ccomp /in <myinlib> /<mylib>; extensions
If I try to use BIND it also generates an error. Specifyin my files are not code 100.
They are: source code 101 and "executable" 800.
The manual tells me to use BIND, buy I can't find a way to compile to maybe object.
What am I missing?
thanks for your help.
If you don't want to try to figure out using eld, I believe this would work for you, except for a possible problem I mention further below:
ccomp /in <myin> /<myout>; runnable, extensions, eld(-local_libname <mylib>)
I am not sure whether the minus character is to be included in the eld argument.
The possible problem is that the ELD manual says that user libraries are DLLs, not ordinary object files, like they were on older types of NonStop systems. If that is true, then your simple compile for producing <mylib> will not produce the DLL that you need.
This could just be a bit of confusion in the manual if user libraries must be DLLs only on NonStop X, because the manual that describes ELD also describes XLD (the ELD equivalent for the NonStop X systems), so if something is true for one system type but not the other, the manual might not make that clear.
I have created and used user libraries on older system types, but not on TNS/E, so I don't know whether the manual is correct. Since it would be easy for you to try using the ordinary linkfile that the regular compilation for <mylib> will create, I'd suggest you try using it in the syntax for the ccomp command I gave you above. If it works, great. If not, you'll have to decide what to do next.
In case I got the syntax for that command with the ELD pragma wrong, if you cannot get that to work, compile <myout> without the ELD pragma, then try running your program like this:
rund <myout>/lib <mylib>/
If <mylib> is an acceptable user library file, you should get a debug or inspect prompt, from which you can stop the program. If <mylib> is not an acceptable user library file, you should get a clear error message that says it is not acceptable.
If using an ordinary linkfile as a user library does not work, I think you have these choices:
1. Create a .ar file from your linkfile and statically link the functions from <mylib> with your program when producing the runnable file.
2. Use your <mylib> file as another input to the compiler to statically link the whole thing in the runnable file.
3. Create a DLL from your <mylib>
If you want to figure out how to make your user library be a DLL, you'll need to look at the manual "DLL Programmer's Guide for TNS/E and TNS/X Systems". I don't know how to do that.
If you you want to include your whole <mylib> statically linked into your program, you should be able to use the command:
ccomp /in <myin> /<myout>; runnable, extensions, linkfile "<mylib>"
If you want to put your <mylib> into an archive file, you might have to do your compilation in the OSS environment, since I'm not sure you can create and use archive files in the Guardian environment on TNS/E systems. It is not hard to create a Guardian runnable program from the OSS environment, but switching over to that might be more trouble than it is worth to you. The main advantage of using archive files is that the linker will only include into the runnable file the functions from the archive file that actually are referenced, not all of the functions in the file, as is done for ordinary linkfiles.
If the reason you were using a user library is that you ran out of code space in your previous environment, you probably no longer need to use a user library, since native object files have a huge amount of code space available. The second option probably would be fine for you.
If the reason you were using a user library is that you must sometimes use your program with one version of <mylib> and other times must use your program with a different version of <mylib>, then you probably either will have to create two versions of your runnable program <myout> or you will have to learn how to create a DLL from <mylib>.
If you were using a user library for some other reason, you'll have to decide which way to proceed makes sense for your situation.