Archlinux

[VileLasagna]

Initial porting to Arch Linux (implements #10 ). Current state is:

• Src install is apparently working fine

• Packaging is disabled, I've introduced exit code 2 to the scripts to represent a deliberate abort

  • Code is still there commented out to serve as guide when sorting this out

• READMEs updated

• DKMS related files gone. Given how fast Arch rolls, they're likely to be unnecessary anyway

• Most of the changes are simply disabling packaging and "correcting" package manager calls

• There are, however, three specific workarounds:

  • 03_00_rocblas.sh has a sed call to avoid wrong python executable being selected. There is a comment mentioning a PR, as of the opening of THIS PR, that one has actually been merged into their develop branch and should be in on the next release
  • 03_01_hipblas.sh has a different fix that prevents the build from failing on its own if CUDA is at all installed (it tries to enable it if it finds it, regardless of any options you are able to provide, but can't build for CUDA and HIP at the same time)
  • 01_07_opencl.sh has another python2 related fix, this time merely explicitly calling it instead of "standard python interpreter`

[jlgreathouse]

Hi @VileLasagna

Thanks for submitting this. I won't be able to get around to testing / reviewing this until next week due to some other high priority work on my plate right now. However, I wanted to note that I've seen this and I'm thankful for your help!

[hameerabbasi]

Hello, I can help test, but probably not review. I'm getting the following error:

./00_prepare_system_arch.sh: line 28: parse_args: command not found
"parse_args "$@"" command failed with exit code 127.

I'm assuming you forgot some package... I actually did install argparser via AUR but it doesn't seem to work.

[VileLasagna]

This is a bit weird. I'm pretty sure parse_args should be a bash command itself? I'll nevertheless have a look later today

[hameerabbasi]

I thought the same at first... But a simple Google search for "parse_args bash" reveals that's not the case. Is this what you're looking for? https://github.com/flyingangel/argparser or https://aur.archlinux.org/packages/argparser-bash/

[VileLasagna]

Hello, man. Sorry I didn't get back to you earlier. Accidentally marked the email as read and this slip my mind.

So, the parse_args function is defined in common_options which is sourced. the way this happens is:

BASE_DIR=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)
.
.
.
source "$BASE_DIR/common_options.sh"
parse_args "$@"

I've never used that specific way of getting the current directory so maybe it's breaking if you're calling from a different directory? This I didn't touch from the original files but if it proves annoying, it's easy enough to look more closely

[hameerabbasi]

With master the original issue has been resolved but I face this error now:

Cloning into 'rocminfo'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 72 (delta 0), reused 1 (delta 0), pack-reused 68
Unpacking objects: 100% (72/72), done.
Note: checking out '1bb0ccc'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 1bb0ccc Add hex representation of some values to output
-- The C compiler identification is GNU 8.2.1
-- The CXX compiler identification is GNU 8.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:18 (message):
  Can't find hsa.h.


-- Configuring incomplete, errors occurred!
See also "/tmp/tmp.X97S0nYRWa/rocminfo/build/CMakeFiles/CMakeOutput.log".
"cmake .. -DCMAKE_BUILD_TYPE=${ROCM_CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${ROCM_OUTPUT_DIR}/ -DCPACK_PACKAGING_INSTALL_PREFIX=${ROCM_OUTPUT_DIR}/ -DCPACK_GENERATOR=DEB" command failed with exit code 1.
"${BASE_DIR}/component_scripts/01_05_rocminfo.sh "$@"" command failed with exit code 1.

I'm sorry for taking so long, again.

[VileLasagna]

You say master but that is curious as this hasn't been merged yet...

Not being able to find the header would indicate that either you aren't installing the packages as you go or that you're deploying them to a different folder and haven't passed the correct "output and input" folders for your local deployment.

Sry I haven't been able to look at this more closely, I'm a bit sidetracked with another project for a bit, but do plan on coming back for further changes.

Of note: Both of my pull requests in rocblas and hipblas have been accepted so once the version of those libraries roll over I can drop the workarounds on this side

[lucianolorenti]

@VileLasagna Thank you for your great job!

I was able to build all the stack and the python3 tensorflow package with the current state of this branch.

I had to make two changes though, besides removing python2-z3 from 01_07_opencl.sh

• upgrade ROCM_HIP_CHECKOUT to tags/roc-2.5.0. Firstly, I compiled everything as is, but then I had to upgrade ROCM_HIP and recompile the packages listed here https://github.com/ROCmSoftwarePlatform/tensorflow-upstream/issues/357#issuecomment-473539412 because I was having errors with hipSymbolName (I really don't know if the recompilation of those additional packages were necessary)

• Finally, I had to force libmiopengemm to link with opencl because it was not happening and at the moment of loading all the libraries related to the GPU inside python, some undefined symbols arose.

[VileLasagna]

Hey, @lucianolorenti Thx.

Curious about the OpenCL stuff. I'll try and have a look in the near(ish) future and see if I can inject some workaround.

As for versions, in both additional distros that I've added support for, I've elected to not touch the versions, as they come from a common file to centralise everything. I'm expecting that with the release of Navi in the near future, this project will need and, hopefully get, a version bump on master and, when it does, I'll update the branch. Until then, I'm avoiding diverging as much as I can