urbanjost / m_system Goto Github PK

View Code? Open in Web Editor NEW

14.0 2.0 1.0 11.99 MB

Call C system routines (mostly POSIX) from Fortran

License: The Unlicense

C 6.11% Fortran 92.59% Makefile 1.30%

fortran posix system fpm fortran-package-manager

m_system's Introduction

M_system

Name

M_system - Fortran module for calling basic (mostly POSIX) C system routines

Description

M_system(3f) is a module that allows Fortran to call commonly available C routines that perform basic system operations like creating and deleting files and directories, changing and querying file permits, getting basic ID and process information, ... and other POSIX system requests.

MSWindows systems are not POSIX compliant, so on those platforms you would need to use the Windows Subsystem for Linux (WSL) on Windows 10 or install CygWin or a similar product.

Download and Build

Just download the github repository, enter the src/ directory and run make:

     git clone https://github.com/urbanjost/M_system.git
     cd M_system/src
     # change Makefile if not using one of the listed compilers

     # for gfortran
     make clean
     make gfortran

     # for ifort
     make clean
     make ifort

     # for nvfortran
     make clean
     make nvfortran

This will compile the M_system module and build all the example programs in the PROGRAMS/ directory. There is an example program for each procedure that is also part of the manpage for each procedure.

Supports FPM

(registered at the fpm(1) registry )

Alternatively, download the github repository and build it with fpm ( as described at Fortran Package Manager )

     git clone https://github.com/urbanjost/M_system.git
     cd M_system
     fpm build
     fpm test

This will compile the M_system module and build all the example programs from
the document pages in the PROGRAMS/ sub-directory.

or just list it as a dependency in your fpm.toml project file.

```toml
     [dependencies]
     M_system        = { git = "https://github.com/urbanjost/M_system.git" }

Note that the unit test is dependent on several other modules built via fpm(1) so it can not be run from the standard Makefile described above (ie. the test requires several other modules not in this repository but if you are on the network fpm(1) will download and build those for the test automatically).

Documentation

User

There are man-pages. These have been rendered into HTML and can be browsed one procedure at a time using the manpage index
or as a combined file in a Javascript BOOK
The man-pages themselves can be installed On Unix-like systems for use with the man(1) command:
- manpages.zip
- manpages.tgz
CHANGELOG provides a history of significant changes

Developer Documentation

ford(1) output.

m_system's People

Contributors

Stargazers

Watchers

Forkers

wangvei

m_system's Issues

Cannot build on Windows -- no grp.h file

I have gfortran and gcc installed on Windows. When I try to follow the gfortran instructions, I need to define

CC := gcc

Then I run make F90=gfortran gfortran and get the following error:

c:\fortran\public_domain\github\M_system\src>make F90=gfortran gfortran
makefile:125: warning: overriding recipe for target '.f90.o'
makefile:122: warning: ignoring old recipe for target '.f90.o'
gcc -O   -c -o C-M_system.o C-M_system.c
C-M_system.c:4:10: fatal error: grp.h: No such file or directory
    4 | #include <grp.h>
      |          ^~~~~~~
compilation terminated.
make: *** [<builtin>: C-M_system.o] Error 1

demo_system_dir fail `Substring out of bounds: upper bound (7) of 'wildtext' exceeds string length (6)`

$ fpm new --app m_system-bug
$ cd m_system-bug/
$ cat fpm.toml
...
[dependencies]
M_system = {git = "https://github.com/urbanjost/M_system.git"}
$ cat app/main.f90 
program main
  use M_system, only : system_dir
  implicit none
  write(*, "(a)") system_dir(pattern="*.f90")
end program main

$ fpm run --compiler gfortran-11 --profile debug 
 + mkdir -p build/dependencies
Initialised empty Git repository in ...
remote: Enumerating objects: 595, done.
remote: Counting objects: 100% (595/595), done.
remote: Compressing objects: 100% (298/298), done.
remote: Total 595 (delta 352), reused 435 (delta 285), pack-reused 0
Receiving objects: 100% (595/595), 1.76 MiB | 6.63 MiB/s, done.
Resolving deltas: 100% (352/352), done.
From https://github.com/urbanjost/M_system
 * branch            HEAD       -> FETCH_HEAD
C-M_system.c                           done.
M_system.F90                           done.
libm_system-bug.a                      done.
main.f90                               done.
m_system-bug                           done.
[100%] Project compiled successfully.
At line 5477 of file build/dependencies/M_system/src/M_system.F90
Fortran runtime error: Substring out of bounds: upper bound (7) of 'wildtext' exceeds string length (6)

Error termination. Backtrace:
#0  0x7fb0edcfd970 in ???
#1  0x7fb0edcfe4f9 in ???
#2  0x7fb0edcfeaf6 in ???
#3  0x55f9db9e87db in matchw
	at build/dependencies/M_system/src/M_system.F90:5477
#4  0x55f9db9e9eab in __m_system_MOD_system_dir
	at build/dependencies/M_system/src/M_system.F90:5420
#5  0x55f9db9e77e9 in MAIN__
	at app/main.f90:4
#6  0x55f9db9e789f in main
	at app/main.f90:2
<ERROR> Execution for object " m_system-bug " returned exit code  2
<ERROR> *cmd_run*:stopping due to failed executions
STOP 2

$ gfortran-11 -v
Using built-in specs.
COLLECT_GCC=gfortran-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-2ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-PfdVzN/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-PfdVzN/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-2ubuntu1~20.04)

Unfortunately, I cannot test at the moment other versions of gfortran or ifort, ifx

Funny behavior with -finit-local-zero

When compiling the Fortran code with -finit-local-zero, the statement
integer(kind=c_long),bind(c,name="longest_env_variable") :: longest_env_variable

instantiates the variable:

% gfortran -finit-local-zero -c M_system.f90
% readelf -s M_system.o | grep longest
41: 0000000000000448 8 OBJECT GLOBAL HIDDEN 4 longest_env_variable

% gfortran -c M_system.f90
% readelf -s M_system.o | grep longest
41: 0000000000000008 8 OBJECT GLOBAL HIDDEN COM longest_env_variable

and therefore, if you want to link the C and Fortran code you end up with a "multiple definitions" error.

I suppose that the answer to this issue is, in principle, to not compile with -finit-local-zero. In practice it's often a hassle to build individual files with different flags.

The gcc manual reads "The -finit-local-zero option instructs the compiler to initialize local INTEGER, REAL, and COMPLEX variables to zero". Apparently this also applies to variables that are bound to C objects.

The issue also applies to FHOST_NAME_MAX.

I am not sure whether you consider this an issue of the compiler, or my attempt in using your library with -finit-local-zero. But if we could come up with a solution that works with and without -finit-local-zero that might be good?