[CMake] Cross-compiling for z/OS -- linker question

Phil Smith phil at voltage.com
Wed Sep 3 22:52:04 EDT 2008


Thanks; I gave up on trying to get long filenames to work. There are too many levels involved, and if you get it right on 1-n, then n+1 messes it up, etc., etc.

Right, the I took out the FORCE_C_COMPILER stuff. But it still breaks things it shouldn't.

z/OS is indeed not the only OS on System z; that's why I was asking before about the nomenclature (OS vs. platform etc.).  The good news is, anybody on System z knows about z/OS and knows that it's the "big dog", so we're OK using that name, rather than ANY_SYSTEM_Z_OS or something (!).  (I came from the world of one of the other System z OSes, so I think I can say that with some confidence: we've spent decades reminding people that "z/OS" isn't the only OS, but given that we have to choose something...)

Once this finally settles down once and for all (we're still fighting other fires, but I think CMake is a resolved issue) I'll look into submitting a patch.

Related question: I hacked CheckTypeSize.cmake to MESSAGE the OUTPUT variable after a compile, since it was claiming to work but actually failing (leaving no values for the types in CMakeCache.txt).  Some grepping of the CMAKE files and the source failed to reveal any way that the --debug_output flag was exposed to the macros; did I miss it?  It would be nice to have a way to see the compiler output.

...phsiii
-----Original Message-----
From: Alexander Neundorf [mailto:a.neundorf-work at gmx.net]
Sent: Wednesday, September 03, 2008 6:04 PM
To: Phil Smith
Cc: cmake at cmake.org
Subject: Re: [CMake] Cross-compiling for z/OS -- linker question

On Monday 25 August 2008, Phil Smith wrote:
> I'm back on this, after a week at a conference and a week of vacation.
>
> I have the GET_FILENAME_COMPONENT call working, and it returns what I'd
> expect (c:/progra~1/dignus), but the FIND_PROGRAM resolves the path with
> blanks (c:/Program Files/Dignus/plink.exe).  Here's the CMAKE code I'm
> using, in ZOS.cmake:
>
> GET_FILENAME_COMPONENT(PLINKPATH "${CMAKE_C_COMPILER}" PATH)
> MESSAGE(STATUS "PLINK path is ${PLINKPATH}!")
> FIND_PROGRAM(PLINK_EXECUTABLE NAMES plink PATHS "${PLINKPATH}"
> NO_DEFAULT_PATH) MESSAGE(STATUS "PLINK_EXECUTABLE is ${PLINK_EXECUTABLE}!")
> SET(CMAKE_CXX_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
> \"-Sc:/progra~1/dignus/objs_rent/&M\" <OBJECTS> -o <TARGET>")
> SET(CMAKE_C_LINK_EXECUTABLE   "${PLINK_EXECUTABLE}
> \"-Sc:/progra~1/dignus/objs_rent/&M\" <OBJECTS> -o <TARGET>")
>
> That barfs all over the place. The two MESSAGE calls show:
> -- PLINK path is c:/progra~1/dignus!
> -- PLINK_EXECUTABLE is C:/Program Files/Dignus/plink.exe!
> (And if I put the "progra~1"-format path back in manually, it works again.)

Hmm, the output from MESSAGE() looks as I would expect. What's wrong with
it/what exactly does "barfs all over the place" mean ?

> I also realized that I think there will be a change needed to
> CheckTypeSize.cmake after all: the -fasciiout flag only makes sense during
> that call, as during actual compiles, one will NOT want it set.  Something
> like (around line 60): IF(ZOS)
>       SET(MACRO_CHECK_TYPE_SIZE_FLAGS "${MACRO_CHECK_TYPE_SIZE_FLAGS}
> -fasciiout") ENDIF(ZOS)

Hmm, looks ugly but maybe we'll have to do something like this :-/

> Finally, I'm also still trying to figure out how to name things most
correctly.  You said a couple of things before:
> >Well, the initial tests for the compiler should work without the
> >CMakeForceCompiler stuff. If this works, then CMakeC[XX]CompilerId.c.in
> > cmake should be able to detect that it's the Dignus compiler, and set
> >CMAKE_C_COMPILER_ID to "Dignus". Once this is works, it then tries to load
> >Modules/Platform/ZOS-Dignus-C.cmake (and ZOS-Dignus-CXX.cmake).
> >These files should then contain the settings which are specific for that
> >combination of operating system, and compiler.
> >E.g CMAKE_C_LINK_EXECUTABLE and maybe more.
>
> and:
> > No, it's <SYSTEM>-<COMPILER_ID>-<LANGUAGE>.cmake
> >with SYSTEM being the name of the operating system.
>
> But what I don't see is how it's going to figure out that the compiler is
> named Dignus, since the CMAKE_FORCE_C_COMPILER stuff breaks everything.

"breaks everything" ?
Aren't we trying right now to get rid of the FORCE_C_COMPILER stuff ? It
shouldn't break anything, since it's not called anymore :-)

> Maybe I don't care that much that the compiler gets identified fully -- do
> I?  It's the one and only likely compiler to be used for z, now and forever

But I guess zOS is not the only OS the compiler can be used for ?
So getting this to work should help using Dignus on other platforms.

Alex


More information about the CMake mailing list