On 06/17/2015 11:07 AM, Ette, Anthony (CDS) wrote:
> Please see the response below about uniquely identifying cf77.
>
> In order to identify the compiler as cf77, do something akin to the following:
> $ echo ' PROGRAM V' > /tmp/nil.f
> $ echo ' END' >> /tmp/nil.f
> $ cf77 -v -o /dev/null
>I've scoured the cf77 docs and found nothing native so I've responded to
>concurrent and again asked how I can find unique identifying information for
>cmake to latch onto. Will report back.
Please see the response below about uniquely identifying cf77. Does this seem
doable? How do we proc
> What is the output of "cf77 --version"?
Garbage (see below):
rts1-4:/home/bzpl46> cf77 --version
cf77 Fatal Error: invalid flag -io
I've scoured the cf77 docs and found nothing native so I've responded to
concurrent and again asked how I can find unique identifying information for
cmake to lat
On 06/16/2015 01:44 PM, Ette, Anthony (CDS) wrote:
> I'm still struggling getting anything unique from the cf77 command line.
What is the output of "cf77 --version"?
> Okay, the -rdynamic option to cf77 instructs it to build
> a shared object (shared library), not an executable program.
That may
> http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.3.0-rc2#l114
Ok. I'm still struggling getting anything unique from the cf77 command line.
They have plenty of custom functions that can be invoked outside of cf77 but
that wouldn't be suitable
On 06/16/2015 10:00 AM, Ette, Anthony (CDS) wrote:
>> That shows it can be reproduced locally outside of CMake.
>> Please try dropping -rdynamic from that command line.
>
> Ahh, you are correct. Success! What does this mean?
This means CMake needs to be able to define and detect an
id for this
> Ahh, you are correct. Success! What does this mean?
I found this in the cf77 release notes, not sure if it means anything to us at
this point.
Linking with gcc, g++ or g77:
This release ships with its own updated linker (ld) that can interpret DWARF 3.
If you link cf77generated code using t
>> rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp> /usr/ccs/bin/cf77
>> CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o
>> cmTryCompileExec3453195864 -rdynamic
>> /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt
>That shows it can be reproduced locally outside of CMake.
>Pl
On 06/16/2015 09:31 AM, Ette, Anthony (CDS) wrote:
> rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp> /usr/ccs/bin/cf77
> CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o
> cmTryCompileExec3453195864 -rdynamic
> /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt
That shows it c
> Very little. The whole point is to test that the compiler works the way
> CMake will invoke it in the generated build system.
But the user does have tons of control over the generated build system so why
can't he have same control have test program compilation? I think in this case
someone
On 06/16/2015 01:21 AM, Ette, Anthony (CDS) wrote:
> what control does the user have over the compilation of the test program?
Very little. The whole point is to test that the compiler works the way
CMake will invoke it in the generated build system.
> I.e. can I tell cmake to add -L (where to l
>The environment is not for CMake but for the compiler itself. I was just
>saying that CMake is not going to know what environment variables the
>toolchain needs to have set in order for the compiler >to work.
>If you invoke CMake from the same environment as that by-hand test that worked
>earl
On 06/15/2015 03:42 PM, Ette, Anthony (CDS) wrote:
> you mention that it is my responsibility to setup the environment
> before invoking Cmake and while I agree, it's just not clear to me
> what speficially Cmake requires to be setup.
The environment is not for CMake but for the compiler itself.
>Some information is considered but not all. Try a minimal CMakeLists.txt:
> cmake_minimum_required(VERSION ...)
> project(TestProject Fortran)
>Does this enable Fortran correctly with cf77? If so then you can start
>stripping down your project to debug this.
No joy. Same error. Must mean tha
On 06/15/2015 03:08 PM, Ette, Anthony (CDS) wrote:
>> Okay. If -lrt is the default for the compiler why might "rt" not be found?
> say if one of my CMakeFiles.txt had "SET(CMAKE_CXX_LINK_FLAGS "-lrt")")
> or are my CMakeFiles.txt not considered as part of building a simple
> test program?
Some in
> Is the compiler hosted natively on that platform or are you cross-compiling
> to it?
Hosted natively. I wouldn't normally try to use a toolchain file to overcome
this because I'm not really cross-compiling here, but it one of the mechanisms
that I though *may* work. I don't want to go agains
On 06/15/2015 01:53 PM, Ette, Anthony (CDS) wrote:
> Thank you for the response. I suppose I should've provided
> more information about the platform up front. Our system is a
> RHEL5 variant named "RedHawk Linux". The kernel is a custom
> real-time kernel developed by Concurrent Computer Corpor
Brad,
Thank you for the response. I suppose I should've provided more information
about the platform up front. Our system is a RHEL5 variant named "RedHawk
Linux". The kernel is a custom real-time kernel developed by Concurrent
Computer Corporation and cf77 is a real-time port of the GNU f77
On 06/15/2015 11:31 AM, Ette, Anthony (CDS) wrote:
> Any ideas? Our FORTRAN compiler (Concurrent Computer Corporation
> port of f77) is failing to compile simple test program because the
> linker can't find -lrt
>From the log:
> /usr/ccs/bin/cf77 -c
> /home/bzpl46/sandbox/AE3007/C2/build/redh
Any ideas? Our FORTRAN compiler (Concurrent Computer Corporation port of f77)
is failing to compile simple test program because the linker can't find -lrt
(highlighted below). Have you ever seen anything like this? How can I remedy?
-- Check for working CXX compiler: /usr/bin/g++ -- works
--
20 matches
Mail list logo
