ld for VMS?

Jay K jay.krell@cornell.edu
Mon May 3 11:16:00 GMT 2010

The memcpy problem was #define __size_t. Moving along.. :)

 > decc$crtl_init

Presumably related to decc$main? I'll check the docs.

> how do I copy

The VMS machine has a web server, just serving out a directory, it lists files, I click
on them, they download. I've tried bare .obj files and .zips.
The .zips certainly work in general since that's how I got the headers and libraries.
I could use .tar.gz also but haven't been.

To copy to VMS (hello.exe) I use sftp.
sftp might also work to copy from VMS, though the one time I tried it exited, not sure if it was before
or after the copy.

For some reason scp isn't working, which is what I'd normally use.
 It complains about an extra newline or such.
I can also probably email uuencoded files.

If I'm really successful on this project, maybe I can get a working cross-built openssh/scp..

Given the handler isn't needed, I'm fine with gcc-built crt0.c.
Presumably the patch is either to remove the handler and just compile with gcc, or #ifdef __GNUC__ around it.
And then update the makefile chunks.

alpha64-dec-vms has additional problems because of the pointer size stuff, though I don't get it.
If the pointers are indeed 32bits, declare that they are ints and extend them to long, and pass long
pointers to main (assuming main is compiled with gcc..and assuming gcc doesn't do something
funny for main). I don't see why the copying is done.

 - Jay

> Subject: Re: ld for VMS?
> From: gingold@adacore.com
> Date: Mon, 3 May 2010 12:53:53 +0200
> CC: becker.ismaning@freenet.de; rupp@gnat.com; binutils@sourceware.org
> To: jay.krell@cornell.edu
> On May 3, 2010, at 12:13 PM, Jay K wrote:
>> This is why I thought so:
>> http://h71000.www7.hp.com/doc/83final/5763/5763pro_069.html
>> To cause an OpenVMS exception to generate a UNIX style signal, user exception handlers must return SS$_RESIGNAL upon receiving any exception that they do not want to handle. Returning SS$_NORMAL prevents the generation of a UNIX style signal. UNIX signals are generated as if by an exception handler in the stack frame of the main C program. Not all OpenVMS exceptions correspond to UNIX signals. See Chapter 4 for more information on the interaction of OpenVMS exceptions and UNIX style signals.
>> Though that doesn't say what happens if there is no handler, only what handlers should do.
> The handler is installed by decc$crtl_init using a global vector. Thus the condition handler for
> main is not required. Of course, other user condition handlers should return SS$_RESIGNAL on condition
> that they don't handle.
> (But this is more a gcc topic!)
>>> NB: for gcc specific issues, you'd better to post on gcc@gcc.gnu.org
>> Right, sorry. They are imho very intermingled and my original query was for an ld. Granted, we got way past that a while ago: "use head".
>>> Good luck. How do you handle the include issue ? Ie, do you have the VMS specific includes ?
>> Same way I got hello world to work (since it had an #include and uses libraries).
>> Yes. I have /usr/local/alpha-dec-vms/lib and /usr/local/alpha-dec-vms/include, contents
>> copied from the VMS machine, the libraries/olbs or at least some converted/expanded/compressed, the headers hacked
>> slightly with #define __int64 long long.
>> I don't "like" this, but it is the way.
>> Among other things -- which files to copy?
>> I end up copying surely way too much.
> I think that's it.
>> I don't get too far yet..there is something wierd with memcpy.
>> Compiling libiberty/regex.c as part of gcc says wrong number of parameters.
>> I have to look more closely.
>> I swear removing the space after one instance of memcpy helped, but not the other.
>> memcpy is a macro:
>> #define memcpy(a, b, c) __MEMCPY(...stuff...)
> I haven't hit this issue (yet ?)
>> There is still something wierd where GNU ld doesn't like .obj files output by VMS cc.
>> In particular, vms-crt0.c cannot actually be compiled by VMS cc, nor out of the box by gcc.
> How do you copy from VMS to unix ?
> Tristan.

More information about the Binutils mailing list