Ralf Wildenhues wrote:
Hi John,
[ not responding to everyting ]
* John E. Malmberg wrote on Mon, Dec 05, 2005 at 09:14:05PM CET:
So it would be better if the library authors provided a list.
Hmm. Maybe you can convince a few. If the list can be kept platform-
independent, maybe a few more people will move to using
-export-symbols-list..
It may be possible to put a sanity check in to see if the
-export-symbols-list supplied file
However, the AR emulation on OpenVMS does not always create a library,
sometimes it just concatenates the object files.
What's the difference in semantics to a, say, unix-like ar?
I am not totally sure. I know that some functions are not implemented
by the implementation I have and are just ignored with a diagnostic.
OpenVMS has native support for indexed files. An object library is
stored in such a way as a standard format, and the linker knows how to
use it, but it needs to be told that it is processing a library.
The native librarian utility can also retrieve the original files from a
library.
Some of the functions of ar do not map to what the librarian does, and
also in order to the shell scripts to work, instead of building object
libraries, it apparently was better just to concatenate the object files
together, because then the LD emulation does not have to try to figure
out if it is being given a library or an object file.
Things may get even more interesting with OpenVMS on I64, as the object
module format is ELF with some OpenVMS extensions that have been added
to the ELF specification. Which means that if GCC and the other support
tools also start supporting those extensions, it may be possible in some
(probably rare) cases to exchange usable binaries or cross compile
to/from LINUX on I64.
-John
[EMAIL PROTECTED]
Personal Opinion Only
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
