HP cc compiler for assembly

[Robin_Geffroy]

Hello,

I hope this was not asked before -- I was unable to find any relevant information, neither on the cc manual or online.

I have an issue with HP-UX cc compiler and assembly code.

The command line succeed, but does not generate any output. I think I know the reason, but it bothers me and I'm trying to find a workaround.

Here is the command line (simplified): cc -c -o foo.o foo.s

Like this, it works smoothly. However, if I rename foo.s to foo.S or foo.sx, it does not.

The .s extension indicate pure assembly. The .S or .sx extension are for assembly with macro (#define for instance)

On other OS (linux-ia64 with gcc), if I try to compile a .s file with macro, it fails (macro are not handled, gcc works as expected). If I compile it as a .S or .sx, it works fine.

On HPUX, it *only* works with .s file !

Is there a way (a cc option, or maybe an update ?) to handle .S / .sx file with cc ?

Current cc version is cc: HP C/aC++ B3910B A.06.20 [May 13 2008]

I know it's old... But it seems we were unable to update for some reason I don't know about (I'm not an hp-ux admin, just a user). If a more recent cc version fixes it, I'm okay with it.

Test program :

#define ADDP add
.text
ADDP r27=4,r35

On linux-ia64 :

gcc -c foo.s => failure

gcc -c foo.S / gcc -c foo.sx => success

On hpux-ia64 :

cc -c foo.s => success

gcc -c foo.S / gcc -c foo.sx : return code 0, but no .o generated

Regards,

Robin

[Steven Schweda]

> Current cc version is cc: HP C/aC++ B3910B A.06.20 [May 13 2008]

   On what?

      uname -a

> [...] If a more recent cc version fixes it, I'm okay with it.

   But is HP[E] "okay with it"?  If you have a support contract, then
I'd ask HP[E].  If not, then I don't know how you'd get a newer
compiler.

   I haven't written anything in assembly language since an 1132 printer
driver for the IBM 1130, so I know nothing, but...

> On other OS (linux-ia64 with gcc), [...]

   If GCC does what you want, then I might investigate GCC on HP-UX.  I
use it on my (old) HP-UX systems.

   If there's some requirement to use the HP[E] C compiler, then I might
try writing my own shell script to run a source file through "cpp", and
present the result to the lame C compiler.  Some adjustment to the build
procedure (like, say, a new "make" rule) might be needed/helpful for
that.

[Robin_Geffroy]

I got this issue on two HP-UX (both PA-RISC an ia64)

HP-UX hpx33 B.11.31 U 9000/800 417101946 unlimited-user license

HP-UX hpx34 B.11.31 U ia64 0128802988 unlimited-user license

The issue is not the OS, but the compiler itself.

What I meant was not "I am going to update", just "is that a compiler issue that occured on old version and is now fixed". If it's fixed on newer OS, I won't look any further and check if we can have an up-to-date compiler.

I know it works with gcc, but we'd like to stick with the native compiler.  And if it was only for a "personal" project, I'd have no issue with modifying it. But it's for an open source library, and I'm not familiar enough with the project architecture. I opened an issue and they might be working on it, but, once again, if a newer compiler does the trick, they should not bother with old, broken version. A "simple" fix would be to have the file named "foo.S" on all OSes, except for HP-UX where it should be named "foo.s". Or with a build option (because if you build the library on HP-UX with gcc, it *must* be named foo.S and not foo.s... It's just the HP native that is silly )

If you have access to a newer version of the compiler, you can just do the test I proposed and tell me whether or not it works, that would already be helpful.

Thanks for your answer.

[Steven Schweda]

> The issue is not the OS, but the compiler itself.

   I'd guess that not all compiler versions are available for all HP-UX
versions, and, with my weak psychic powers, I couldn't tell if your OS
dated from 2008, too.

> I know it works with gcc, but we'd like to stick with the native
> compiler. [...]

   Why?  Because it works so well for everything you do?

> [...] A "simple" fix would be to have the file named "foo.S" on all
> OSes, except for HP-UX [...]

   Not how I'd deal with it. Especially considering that there may be
GCC users on HP-UX who don't need the "help".

> [...] It's just the HP native that is silly )

   The HP[E] compiler may be old and/or lame.  But, if all it lacks is
the ability to run a ".[sS]" file through its "cpp", then I'd work on
that shell script, and do the build with "CC=my_cc_script".  It's not
obvious to me that any other changes to your (unspecified) "an open
source library" would be needed.

> If you have access to a newer version of the compiler, [...]

   I'm a mere hobbyist/peon, with no access to any HP[E] C compilers
beyond the (crippled) "bundled" compiler which comes with the OS.  As I
said, I use GCC.  If I wanted info on the current HP[E] compiler, then
I might consult the current documentation, or ask HPE.  Or wait for
advice from the better informed.

[Robin_Geffroy]

> I'd guess that not all compiler versions are available for all HP-UX
versions, and, with my weak psychic powers, I couldn't tell if your OS
dated from 2008, too.

Have you got to be that passive / agressive ?

> Why? Because it works so well for everything you do?

I don't want to use gcc because I don't want additional dependency, and because we have a lot of libraries built with HP-UX cc, which are not compatible with gcc.

I am just asking "is that fixed in newer cc version or is there a workaround with cc". If your solution is "change the OS", "change the compiler" or something like that, why bother to answer ?

> Not how I'd deal with it. Especially considering that there may be
GCC users on HP-UX who don't need the "help".

Exactly what I explained in my last post.

> The HP[E] compiler may be old and/or lame. But, if all it lacks is
the ability to run a ".[sS]" file through its "cpp", then I'd work on
that shell script, and do the build with "CC=my_cc_script". It's not
obvious to me that any other changes to your (unspecified) "an open
source library" would be needed.

If you want, I can tell : it's OpenSSL. If you don't ask, I won't tell, because it's not relevant here. That's why my question was "Is there a way (a cc option, or maybe an update ?) to handle .S / .sx file with cc ?"

And not "is there a way I can compile a .S file on HP-UX". Using a script might be an idea, but it's more of a dirty workaround (because it will come down to "cp foo.S foo.s ; cc foo.s" instead of "cc foo.S"). Thus my original question.

> I'm a mere hobbyist/peon, with no access to any HP[E] C compilers
beyond the (crippled) "bundled" compiler which comes with the OS. As I
said, I use GCC. If I wanted info on the current HP[E] compiler, then
I might consult the current documentation, or ask HPE. Or wait for
advice from the better informed.

The bundled compiler is what I want. But you might have a newer version than me, or someone else might. The current documentation (that I know of) does not say anything about that. I can't ask HPE directly, because I have no access. I'll have to ask my IT departement to ask HPE, and it will be long and unpractical.

Thus the question here, because either someone have access to a newer cc version and can check, or someone already stumbled into this issue and found a not-so-documented option on cc to handle .S files. If not, I can look into the library more to find a way to change it (either with a build option, that can be chosen by the user during the configuration, or automatically detected on HP-UX with bundled compiler). I'm just not familiar enough with the library architecture to do it easily, and I don't want to do some changes that are irrelevant (if it's fixed in newer cc version, it would be a bad idea to do it on all HP-UX with the bundled compiler)

[Steven Schweda]

> Have you got to be that passive / agressive ?

   Do you need to hide so much obviously useful information?

> [...] we have a lot of libraries built with HP-UX cc, which are not
> compatible with gcc.

   "not compatible" _how_?  Lacking a real HP[E] compiler, and not
expecting the bundled compiler to work well, I don't do much mixing.
What, exactly, goes wrong?

> [...] If your solution is "change the OS", "change the compiler" or
> something like that, why bother to answer ?

   I can't determine if there's a solution (or, as requested, "a
workaround") until I can make sense of the problem description.  If I
were using GCC elsewhere, then I don't know why I wouldn't use GCC on
HP-UX.  If you don't want to change _anything_, then why ask for "a
workaround"?

> Exactly what I explained in my last post.

   What is?

> [...] Using a script might be an idea, but it's more of a dirty
> workaround [...]

   You asked for "a workaround".  I offered an idea for a workaround.
Define "dirty workaround".

> The bundled compiler is what I want. [...]

   Another thing which you neglected to mention.  Around here, for
example:

dyi# uname -a
HP-UX dyi B.11.31 U ia64 4235313755 unlimited-user license

dyi# cc --version
(Bundled) cc: HP C/aC++ B3910B A.06.12 [Oct 11 2006]

   As usual, showing actual commands with their actual output can be
more helpful than your summary of what it all means.

   It says "(Bundled)" for a reason.  The bundled compiler was provided
to let the user build a kernel; it was not intended (or supported) for
general use.  HP[E] sold/sells a real, not-intentionally-crippled
compiler for general use.  People bought/buy it because it was more
useful than the bundled compiler.  In the old days, the bundled compiler
was even more crippled:

dy# uname -a
HP-UX dy B.11.11 U 9000/785 2012616114 unlimited-user license

dy $ cc -o mdt mdt.c
(Bundled) cc: "mdt.c", line 10: error 1705: Function prototypes are an ANSI feature.

> [...] I opened an issue and they might be working on it, [...]

> [...] it's OpenSSL. [...]

   Did you tell the OpenSSL folks that you were trying to use the
_bundled_ compiler?  The usual advice for anyone reporting a missing
feature in the bundled compiler always was to buy a real compiler (or
use a free one).

> If you have access to a newer version of the compiler, [...]

   As you can see, mine looks older than yours.

> [...] (if it's fixed in newer cc version, it would be a bad idea to do
> it on all HP-UX with the bundled compiler)

   I'd expect that using the HP-UX bundled compiler for almost anything
(beyond its one purpose) would be a bad idea.

      https://support.hpe.com/hpesc/public/docDisplay?docId=c02877344

      The bundled cc compiler is only meant for use to regenerate the
      kernel. It is not intended or supported for use with application
      development and is not an Ansi compliant compiler.

(The "not an Ansi compliant compiler" bit might be left over from the
old days, when it obviously wasn't.)

      https://community.hpe.com/t5/x/x/td-p/7064970

[Robin_Geffroy]

> Do you need to hide so much obviously useful information?

I didn't know it was "obviously useful", otherwise I would have given it. Like I did when you simply asked. You don't have to be unpleasant while asking.

> "not compatible" _how_? Lacking a real HP[E] compiler, and not
expecting the bundled compiler to work well, I don't do much mixing.
What, exactly, goes wrong?

Not compatible like any library built with gcc can't link with a library / an executable built with HP-UX cc.

> I can't determine if there's a solution (or, as requested, "a
workaround") until I can make sense of the problem description. If I
were using GCC elsewhere, then I don't know why I wouldn't use GCC on
HP-UX. If you don't want to change _anything_, then why ask for "a
workaround"?

As I explained in almost every post : I jsut want to know if the bundled compiler has a way to make it work ("a workaround", as "maybe an option to add", or "update to version XXX"). That is exactly what I want. I said it like that almost everytime, and I don't want to change anything else. I mean, it's a simple question.

> What is?

You were saying "there might be GCC user on HP-UX who don't need the help". That's exactly what I was also saying : "[...] with a build option (because if you build the library on HP-UX with gcc, it *must* be named foo.S and not foo.s... It's just the HP native that is silly )"

> You asked for "a workaround". I offered an idea for a workaround.
Define "dirty workaround".

I asked for a very specific thing : a workaround for the bundled compiler. I didn't ask for anything else. I know I can change the library to make it work, but it would be a lot of work. If a simple cc option exists, it's obviously way better. If using a newer cc version fixes it, it's also better -- and, moreover, it entirely change the fix to implement in the library.

> Another thing which you neglected to mention. Around here, for
example:

As per my first post :

Is there a way (a cc option, or maybe an update ?) to handle .S / .sx file with cc ?

Current cc version is cc: HP C/aC++ B3910B A.06.20 [May 13 2008]

And in my second post, I added the uname information.

I also added the commands :

cc -c foo.s => success

cc -c foo.S / cc -c foo.sx : return code 0, but no .o generated

What do you expect ? An output ? There is none, in all cases. What should I do ?

> Did you tell the OpenSSL folks that you were trying to use the
_bundled_ compiler? The usual advice for anyone reporting a missing
feature in the bundled compiler always was to buy a real compiler (or
use a free one).

I said I use HP cc compiler. Didn't know there was more than one. And, as it seems, they didn't as well. I worked fine with the previous OpenSSL version, which didn't use any .S files.

> As you can see, mine looks older than yours.

So you can't test, and don't know about a (maybe inexisting) option. Fine with me, thanks for your help, and for your time explaining other workarounds, but the cc update / option are the only one I want information about for now.

> I'd expect that using the HP-UX bundled compiler for almost anything
(beyond its one purpose) would be a bad idea.

Okay, I said "bundled" compiler before, because you said it. How do I check ? Because when I use "man cc", it tells nothing about bundled, or "only for kernel".

aCC invokes the HP-UX aC++ compiler. C++ source code is compiled
directly to object code. cc is the HP-UX C compiler. c89 is the
HP-UX ANSI-conforming C89 compiler. c99 is the HP-UX ANSI-conforming
C99 compiler. (If C or cc is mentioned below it usually means it
applies to all C drivers. c89/c99 do not support any -A* options.)

[Robin_Geffroy]

Note :

my bad, I just noticed that, in my first post, I said that on hpux, the .S compilation failed with gcc. I meant "cc", not "gcc". It might induce error.

[Steven Schweda]

> [...] I said "bundled" compiler before, because you said it. How do I
> check ? [...]

> dyi# cc --version
> (Bundled) cc: HP C/aC++ B3910B A.06.12 [Oct 11 2006]
>
> As usual, showing actual commands with their actual output can be
> more helpful than your summary of what it all means.

   If you're _not_ using the "(Bundled)" compiler, then I'd return to my
original advice.

[Robin_Geffroy]

Thanks for the information.

I didn't think having the command ("cc --version") would be useful to know what version it is, since I indicated :

Current cc version is cc: HP C/aC++ B3910B A.06.20 [May 13 2008]

I checked the documentation and did not find anything relevant, sadly. As I explained, I can't easily contact HPE directly. Thus the question here, for the community, hoping for someone using HP-UX cc compiler as well.

Once again, thanks for your time and clarification.