HP3000-L Archives

January 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Emerson, Tom # El Monte" <[log in to unmask]>
Reply To:
Emerson, Tom # El Monte
Date:
Thu, 27 Jan 2000 17:05:01 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
I don't have the answer, but your question gives some insight to a problem
I've been having today -- my conclusion is that the command files supplied
by HP for compiling "C" programs are suitable for "toy/example" programs,
not robust/complex programs...

I've been going around in circles with a program that "simply didn't work",
yet wasn't reporting any errors. [a well-known impossible situation :)]
Now, I'll admit this is "partly my fault", for I had ripped apart the
single-source-to-executable CCXLLK command file and created a "make"-like
jobstream to compile a multi-source file "appropriately".  Seems there is a
test in the command file for "hpcxljcw" and whether or not it has the value
"1" -- all to decide whether it should use a pre-existing indirect file
{ccstdrl.lib.sys) or build this "on-the-fly" as the files libcshr, libcansi,
libmansi, & libcrand all from .lib.sys.  I must have (mistakenly) guessed
that including "-Aa" on the compile string caused this JCW to be set to
something other than 1, because I forced that for this "multi-file"
conglomeration.

To shorten an already lengthening story, I'm compiling what is now a
single-source program that makes use of sockets.  Using this same jobstream,
the program doesn't seem to recognize "errno" -- it's like it just isn't
there...  I finally fixed (?) my job to re-check this [for this single-file
case], and now at least my program is reporting "245" on the connect call...
[the program still doesn't work, but at least I know why now... :)]

Now, to tie this back to your question, there is obviously SOMETHING
different about these RL's because the "global variable errno" isn't being
set in one case, yet is in the other [no actual changes to the source --
just the method of linking at the end...]


> -----Original Message-----
> From: Lee Courtney [mailto:[log in to unmask]]
> Sent: Wednesday, January 26, 2000 11:42 AM
> To: [log in to unmask]
> Subject: MPE/POSIX Binding Question
>
>
> Hi all,
>
> I have an interesting problem that I'm hoping someone may have already
> encountered and solved. The issues concerns binding code
> compiled in the MPE
> domain using CCXL to an archive library compiled with c89 and
> built with ar
> in the POSIX domain.
>
[...]
> I believe, but am not sure, that this approach is kosher.
> There have been
> issues in the past with boundary conditions between libraries
> built using
> MPE and POSIX compilers, but with introduction of shared
> variables in 5.0
> I'm wondering if those problems (e.g. name collisions between
> /lib/lib* and
> [log in to unmask] libraries) have gone away? I'm specifically
> concerned about
> name collisions and externals references between code
> compiled with MPE CCXL
> and POSIX c89.

ATOM RSS1 RSS2