Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't compile using AOCC Compilers #280

Closed
ericnardi opened this issue Jan 23, 2021 · 10 comments
Closed

Can't compile using AOCC Compilers #280

ericnardi opened this issue Jan 23, 2021 · 10 comments
Assignees
Labels
Component - Build CMake, Autotools Priority - 1. High 🔼 These are important issues that should be resolved in the next release Type - Bug / Bugfix Please report security issues to [email protected] instead of creating an issue on GitHub
Milestone

Comments

@ericnardi
Copy link

I'm trying to compile the latest stable release (1.12.0) on a Linux machine, using AMD Optimizing C/C++ Compilers, but I get errors when running make.

The configure step completes succesfully (I have zlib compiled with AOCC and installed to the directory pointed by the PREFIX variable):

./configure --prefix=$PREFIX --with-zlib=$PREFIX --enable-fortran

But when running make, I get the following error:

  FCLD     libhdf5_fortran.la
clang-11: error: unknown argument: '-soname'
clang-11: error: no such file or directory: 'libhdf5_fortran.so.200'
make[3]: *** [Makefile:963: libhdf5_fortran.la] Error 1
make[3]: Leaving directory '/shared/home/enardi/src/hdf5-1.12.0/fortran/src'
make[2]: *** [Makefile:877: all] Error 2
make[2]: Leaving directory '/shared/home/enardi/src/hdf5-1.12.0/fortran/src'
make[1]: *** [Makefile:828: all-recursive] Error 1
make[1]: Leaving directory '/shared/home/enardi/src/hdf5-1.12.0/fortran'
make: *** [Makefile:662: all-recursive] Error 1
@byrnHDF
Copy link
Contributor

byrnHDF commented Jan 24, 2021

From that error log it indicates that the fortran library did not get built and the setting of the so name failed because it could not find the file. Therefore there must be another failure in either the compile of the sources or the linking of the library.

@ericnardi
Copy link
Author

Hi @byrnHDF, thanks for replying.

Yes, actually, it seems like the fortran shared library did not get built because the -soname flag is not identified by this version of the clang compiler, and the way I see it these flags should actually be sent to the linker in this case (via -Wl flags). It seems that libtool doesn't recognize these AOCC compilers very well and these flags are incorrectly set. I have searched around a bit and the developers of FLang already discussed about a similar issue.

For now, I think I'll try manually running the commands to build the shared library and see if Make can continue from there.

@byrnHDF
Copy link
Contributor

byrnHDF commented Feb 15, 2021

Any possibility to try building with CMake, to see if that system can handle this compiler?

@ericnardi
Copy link
Author

Good idea, I just tried it, but no luck...

But now the problem seems different, maybe I am missing something. I get the following errors when trying to compile with CMake:

[ 26%] Linking C executable ../bin/use_append_chunk
cd /shared/home/enardi/src/hdf5-build/test && /shared/opt/gnusoft/bin/cmake -E cmake_link_script CMakeFiles/use_append_chunk.dir/link.txt --verbose=1
/shared/opt/aocc-compiler-2.3.0/bin/clang  -std=c99 -fPIC -O3 -DNDEBUG -L/shared/opt/amdsoft/lib CMakeFiles/use_append_chunk.dir/use_append_chunk.c.o CMakeFiles/use_append_chunk.dir/use_common.c.o -o ../bin/use_append_chunk  -Wl,-rpath,"\$ORIGIN/../lib:\$ORIGIN/" ../bin/libhdf5_test.so.200.0.0 -lm ../bin/libhdf5.so.200.0.0 -ldl
ld.lld: error: ../bin/libhdf5.so.200.0.0: undefined reference to compress2 [--no-allow-shlib-undefined]
ld.lld: error: ../bin/libhdf5.so.200.0.0: undefined reference to inflate [--no-allow-shlib-undefined]
ld.lld: error: ../bin/libhdf5.so.200.0.0: undefined reference to inflateEnd [--no-allow-shlib-undefined]
ld.lld: error: ../bin/libhdf5.so.200.0.0: undefined reference to inflateInit_ [--no-allow-shlib-undefined]
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [test/CMakeFiles/use_append_chunk.dir/build.make:120: bin/use_append_chunk] Error 1
gmake[2]: Leaving directory '/shared/home/enardi/src/hdf5-build'
gmake[1]: *** [CMakeFiles/Makefile2:2692: test/CMakeFiles/use_append_chunk.dir/all] Error 2
gmake[1]: Leaving directory '/shared/home/enardi/src/hdf5-build'
gmake: *** [Makefile:182: all] Error 2

And I tried to manually run the build commands, but 'make' doesn't see the compiled library, it just tries to recompile it and fails with the same error.

@BtbN
Copy link

BtbN commented Aug 24, 2021

I just ran into this myself, and the issue really is libtool/configure horribly misdetecting flang.

To manually fix it, open the generated libtool script (right next to the configure script) after you ran configure.

First, search for CC="clang++" and take note of the values it found there.
Then search for CC="flang" and see that it found nothing/nonsense for the same values. Write in the same values it found for clang++.

In my case, it looked like this after I was done editing:

# A language specific compiler.
CC="flang"

# Is the compiler the GNU compiler?
with_gcc=yes

# Compiler flag to turn off builtin functions.
no_builtin_flag=" -fno-builtin"

# Additional compiler flags for building library objects.
pic_flag=" -fPIC -DPIC"

# How to pass a linker flag through the compiler.
wl="-Wl,"

# Compiler flag to prevent dynamic linking.
link_static_flag="-static"

# Does compiler simultaneously support -c and -o options?
compiler_c_o="yes"

# Whether or not to add -lc for building shared libraries.
build_libtool_need_lc=no

# Whether or not to disallow shared libs when runtime libs are static.
allow_libtool_libs_with_static_runtimes=no

The values below this don't seem to matter/are correct.

After that, the build with AOCC completed successfully.

While at it, another issue I ran into with AOCC was that configure failed, trying to add "-lwp" to the linker flags.
That's because it sees -target-feature -lwp in the linker invocation from flang -v, and decides that it must be a library.
To work around it, manually set FCLIBS.
Right before configure throws the error, it prints out the contents of that variable. Just copy it, but remove -lwp from it, and invoke configure again:

FCLIBS="..." ./configure ...

@derobins
Copy link
Member

AOCC works with develop, @lrknox will check to make sure this is true for all maintenance branches

@lcebaman
Copy link

lcebaman commented Nov 9, 2022

@derobins Are you sure? I am facing problems with develop:
ld.lld: error: can't create dynamic relocation R_X86_64_32S against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output

@derobins derobins added Priority - 1. High 🔼 These are important issues that should be resolved in the next release Component - Build CMake, Autotools Type - Bug / Bugfix Please report security issues to [email protected] instead of creating an issue on GitHub labels May 3, 2023
@derobins derobins added this to the 1.14.3 milestone Oct 9, 2023
@hyoklee
Copy link
Member

hyoklee commented Oct 12, 2023

#3657

@derobins derobins self-assigned this Oct 13, 2023
@derobins
Copy link
Member

This is/was a libtool error. The libtool script that is generated at compile time was missing the "-Wl," prefix necessary for linker options, so "-Wl,-soname" gets parsed as -soname, which fails.

As of October 2023, with AOCC 4.1, c/flang works out of the box w/ shared unless you are using an MPI compiler wrapper. We have a hack for that (at least in the Autotools), which will appear shortly.

This issue will be closed when the PR is merged to develop.

derobins added a commit to derobins/hdf5 that referenced this issue Oct 14, 2023
* Adds a config/clang-fflags options file to support Flang
* Corrects missing "-Wl," from linker options in the libtool wrappers
  when using Flang, the MPI Fortran compiler wrappers, and building
  the shared library. This would often result in unrecognized options
  like -soname.
* Enable -nomp w/ Flang to avoid linking to the OpenMPI library.

CMake can build the parallel, shared library w/ Fortran using AOCC
and Flang, so no changes were needed for that build system.

Fixes GitHub issues HDFGroup#3439, HDFGroup#1588, HDFGroup#366, HDFGroup#280
lrknox pushed a commit that referenced this issue Oct 15, 2023
* Adds a config/clang-fflags options file to support Flang
* Corrects missing "-Wl," from linker options in the libtool wrappers
  when using Flang, the MPI Fortran compiler wrappers, and building
  the shared library. This would often result in unrecognized options
  like -soname.
* Enable -nomp w/ Flang to avoid linking to the OpenMPI library.

CMake can build the parallel, shared library w/ Fortran using AOCC
and Flang, so no changes were needed for that build system.

Fixes GitHub issues #3439, #1588, #366, #280
@derobins
Copy link
Member

Fixed w/ #3674

brtnfld pushed a commit to brtnfld/hdf5 that referenced this issue Oct 16, 2023
* Adds a config/clang-fflags options file to support Flang
* Corrects missing "-Wl," from linker options in the libtool wrappers
  when using Flang, the MPI Fortran compiler wrappers, and building
  the shared library. This would often result in unrecognized options
  like -soname.
* Enable -nomp w/ Flang to avoid linking to the OpenMPI library.

CMake can build the parallel, shared library w/ Fortran using AOCC
and Flang, so no changes were needed for that build system.

Fixes GitHub issues HDFGroup#3439, HDFGroup#1588, HDFGroup#366, HDFGroup#280
jhendersonHDF pushed a commit to jhendersonHDF/hdf5 that referenced this issue Oct 18, 2023
* Adds a config/clang-fflags options file to support Flang
* Corrects missing "-Wl," from linker options in the libtool wrappers
  when using Flang, the MPI Fortran compiler wrappers, and building
  the shared library. This would often result in unrecognized options
  like -soname.
* Enable -nomp w/ Flang to avoid linking to the OpenMPI library.

CMake can build the parallel, shared library w/ Fortran using AOCC
and Flang, so no changes were needed for that build system.

Fixes GitHub issues HDFGroup#3439, HDFGroup#1588, HDFGroup#366, HDFGroup#280
derobins added a commit that referenced this issue Oct 18, 2023
* Address nagfor exceptions stoppage. (#3658)

* added cmake ieee flag for nagfor

* generalized determining the nag compiler

* fixing some misc. NAG warnings

* Simplify. (#3659)


* Address @jhendersonHDF review

* Add expedited testing support to t_filters_parallel (#3665)

* Remove clang warnings (#3656)

* Fixes test failure for gfortran -O2 and -O3, -fdefault-real-16 (#3662)

* added cmake ieee flag for nagfor

* fixes gfortran -O2 and -O3, -fdefault-real-16

* fixed sync

* updated release notes

* Fix link error on clang17/gfortran13/macOS-13 (#3666) (#3671)

* Correct fortran CMake generator expressions (#3670)

* Add AOCC GitHub Action (#3504) (#3657)

* Fix uninitialized subfiling test variable (#3675)

Picked up by gcc 10 on skybridge. Probably spurious, but no harm in
initializing it to a "bad" value.

* Add support for AOCC & Flang w/ the Autotools (#3674)

* Adds a config/clang-fflags options file to support Flang
* Corrects missing "-Wl," from linker options in the libtool wrappers
  when using Flang, the MPI Fortran compiler wrappers, and building
  the shared library. This would often result in unrecognized options
  like -soname.
* Enable -nomp w/ Flang to avoid linking to the OpenMPI library.

CMake can build the parallel, shared library w/ Fortran using AOCC
and Flang, so no changes were needed for that build system.

Fixes GitHub issues #3439, #1588, #366, #280

* Fix a strncpy call to use dest size not src (#3677)

A strncpy call in a path construction call used the size of the src
buffer instead of the dest buffer as the limit n.

This was switched to use the dest size and properly terminate the
string if truncation occurs.

* Remove CANBE_UNUSED() from subfiling VFD (#3678)

This macro was an attempt to quiet warnings about release mode unused
variables that only appear in asserts. It resolves to a void cast, which
doesn't quiet warnings when an assignment has already taken place.

* Suppress MPI_Waitall warnings w/ MPICH (#3680)

MPICH defines MPI_STATUSES_IGNORE (a pointer) to 1, which raises warnings
w/ gcc. This is a known issue that the MPICH devs are not going to fix.

See here:
    pmodels/mpich#5687

This fix suppresses those issues w/ gcc

* Fix a possible NULL pointer dereference in tests (#3676)


The dtypes test could dereference a NULL pointer if a strdup call
failed.

* Fix printf warnings in t_mpi (#3679)

* Fix printf warnings in t_mpi

The type of MPI_Offset varies with implementation. In MPICH, it's long,
which raises warnings when we attempt to use long long format
specifiers. Casting to long long fixes the warnings.

* Fix invalid memory access in S3 comms (#3681)

In the ros3 VFD, passing an empty string parameter to an internal
API call could result in accessing the -1th element of a string.
This would cause failures on big-endian systems like s390x.

This parameter is now checked before writing to the string.

Fixes GitHub #1168

* Add Doxygen for H5Pset_fapl_sec2() (#3685)

*

* switch to using time function instead of date function (#3690)

* Initialize API context MPI types to MPI_BYTE (#3688)

* Add test info output to t_filters_parallel (#3696)

* Suppress format string warnings in subfiling test (#3699)

* Fix unused variable in tselect.c (#3701)

* Fix unused variable warning in H5F_sfile_assert_num (#3700)

* Restore floating-point suffixes in tests (#3698)

A prior commit removed too many F suffixes. This restores the suffixes
for float variables.

* Sync with changes from develop

---------

Co-authored-by: Scot Breitenfeld <[email protected]>
Co-authored-by: H. Joe Lee <[email protected]>
Co-authored-by: Allen Byrne <[email protected]>
Co-authored-by: Dana Robinson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component - Build CMake, Autotools Priority - 1. High 🔼 These are important issues that should be resolved in the next release Type - Bug / Bugfix Please report security issues to [email protected] instead of creating an issue on GitHub
Projects
None yet
Development

No branches or pull requests

7 participants