We should link against numa without hardcoding the path to it.
CMake should determine how to link numa automatically, similar to how rt
and pthread is linked.
Fixes
Change-Id: Ifb9ac30e200c66cbd7f1cf80d25fffef1dcf8d2f
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
Use GNUInstallDirs variables in post install scripts
License file installed in CMAKE_INSTALL_DOCDIR
Change-Id: I182ca292e03787a6c189e8de31d32244b65b5687
These were required back due to dependency issues in earlier ROCm
releases. With thunk being static now and with better dependency
definitions being used, we can remove these
Signed-off-by: Kent Russell <kent.russell@amd.com>
Change-Id: I266a783993edf32811caf027f4289ede0cbfcb16
This is causing issues with side by side, sorry for the noise.
This license location isn't ideal but it's good enough for now.
Change-Id: Iba2a84cedf22466fdaaf3c63b6ea49c9fc277967
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
The copyright file will conflict if multiple thunks are installed. This
should resolve the issue by adding the version to the install path.
Change-Id: Ieac5a3eba979b3e934fb9100f890b92fc7c35d71
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
CPACK doesn't have proper logic for installing the license as described
by CPACK_RESOURCE_FILE_LICENSE.
For Debian packaging, the license is expected to be installed as:
/usr/share/doc/PACKAGENAME/copyright
To do this, I've added a bit of logic for CPACK to copy this into the
package using CPACK_INSTALL_COMMANDS to prep the directory, and
CPACK_INSTALLED_DIRECTORIES to add it to the package. This applies to
both RPM and DEB, so I've added some logic to the spec file to exclude
this file (note that CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION does
not work for files installed with CPACK_INSTALLED_DIRECTORIES).
For RPM install, I've just added a small bit of logic to the spec file
to handle it. The file needs to be copied into the spec working
directory, then a macro is used to handle the rest. Note the license
macro does not work on EL6, but I don't think we want to support this.
Change-Id: I06ce63d300419893cb8274bc504a15633e304d91
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
I used the binary directory instead of the source directory to specify
the spec.in path, which passed local testing since these directories
are in the same location. This is not guarenteed to be true.
Change-Id: I1b49ca8453b9c074a947104c26fb39667d728a8e
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
CPack does not support recommends for RPM generation, so I've generated
a template RPM SPEC files in order to make modifications to allow for
support of recommends.
The spec.in file was generated using the cpack option
"CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE" and was modified very
sparingly to avoid any maintanance burden, e.g. can be easily
regenerated. The CPACK_RPM_USER_BINARY_SPECFILE is then used to specify
the customized template file, instead of using the cmake's template.
From what I understand, the point of these two options is to allow
developers to tailor the specfile to their desire, since rpm spec files
are much more advanced then the equilivent debian file.
Change-Id: I80c69be58a3c57729ed997fd2ce01f5d16b9e9b9
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
For the use of libdrm-amdgpu-amdgpu1 and libdrm-amdgpu, we should use
recommends, as we want these packages installed with a strong dependency
but avoid a strict dependency, since this is enhancement feature.
Using the newer libdrm, which is build for amdgpu-dkms, is ideal since
it will produce more correct marketing names, but should not be mandated
due to two reasons:
- A user may not want to install both libdrms on their system
- The system might not have the newer libdrm available
This patch only fixes the Ubuntu/debian package since recommends is not
properly implemented for the RPM generator for CPACK. For now,
"suggests" will have to do, since it's the closest option we have. I
will investigate if we can get around this issue.
Change-Id: I33a90c3ead235bbbe265238c026933688ea63fe3
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
SUGGESTS doesn't get installed by default by dpkg, it requires
--install-suggests. While the libdrm-amdgpu-amdgpu1 lib might not be
critical to core thunk usage, it's necessary enough to increase the
dependency from weak to strong, thus we use RECOMMENDS instead
Since CPack doesn't support RECOMMENDS for RPMs, and SUGGESTS isn't
strong enough, we just set it as REQUIRED. This should handle any
standard installation situations instead of trying to be fancy to try to
make things exactly the way we want them to be.
Signed-off-by: Kent Russell <kent.russell@amd.com>
Change-Id: I5a676fb4a3fbf5c7b35f503acc30cf01c056266d
This really should be set to conform to distro standards.
Change-Id: I63442b9ad58f70c4691c499b666f7c359dc9609d
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
The infra is in place to make sure that we can get around the issue
where older versions of rpm don't know what "Suggests" is. Using the
HSAKMT_REQUIRES_LIBDRM variable will force the package to require
libdrm-amdgpu1 instead of just suggesting it in newer distros.
Change-Id: I5d595c4e4be5ad8e8c411dcec3a58365e1984f05
This is required for Marketing Name, but Marketing Name isn't a hard
requirement for ROCT, so make it a Suggested package for DEBs.
Adding a commented-out possible solution for RPM-based distros, as
unfortunately SLE <10 and CentOS/RHEL <8 don't know what "SUGGESTS"
means. Potentially we will add a check that the build environment
that determines if we require the REQUIRES field to be used.
Hopefully we can work out the RPM side quickly, but for now enable
SUGGESTS on DEB as a start
Signed-off-by: Kent Russell <kent.russell@amd.com>
Change-Id: Icea689a14c185964e7f47fb23ee432f9b35ccb03
This is required for Marketing Name, but Marketing Name isn't a hard
requirement for ROCT, so make it a Suggested package
Change-Id: Ibafcce2c59dc8bdba90c171e766122bebf548a48
Signed-off-by: Kent Russell <kent.russell@amd.com>
Use the database provided by libdrm-amdgpu,as this is maintained by AMD
Signed-off-by: Mike Li <Tianxinmike.Li@amd.com>
Change-Id: I319a46d833cb23173a77fdff1deae69ea58588b8
Consolidate all thunk components into a single development package
Also declare build dependencies via find_package/library and report the
location of said dependencies during build time
Change-Id: I8524ad1a2d9a664accd93471abacc4bac82b9a7c
Signed-off-by: Kent Russell <kent.russell@amd.com>
This was an implicit requirement, but the change to needing libdrm/drm.h
means we should be explicitly looking for this package during the build
Change-Id: I75064bf6f5477cb1ca99318681afca76c0060f72
Update to thunk API introduced dependency on drm.h in commit
31ac82617c libhsakmt: update thunk api for exception handling
so update dependency list in SLES builds.
Signed-off-by: Jonathan Kim <jonathan.kim@amd.com>
Change-Id: I6d987fac07612e3eca7b6087205d76df50dc13d9
This can be overwritten by changing BUILD_SHARED_LIBS=true, but we
default it to static to allow for merging into ROCr
Change-Id: Ic286ef7903a5bc788fe3b84bb13b15bdd3a6f60b
This reverts commit 75e8fe383f.
SVM is not ready yet. This was merged by accident.
Change-Id: I372f7d293fd38429ec570bc0e0add7e612871594
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Merge in topic branch to enable address sanitizer and CLANG compilation
support into amd-staging branch
Change-Id: I3fcd24c6fac83d0619bef4cbbc56fd95e9fb009d
Signed-off-by: Kent Russell <kent.russell@amd.com>
The %{dist} suffix is part of the package name due to
CPACK_RPM_PACKAGE_RELEASE_DIST, but the string provided to the
"REQUIRES" field lacks it. Add it in here so the devel package can
reference the thunk package correctly. Use a nice function suggested by
Cole since CPACK_RPM_PACKAGE_RELEASE_DIST has caused some infra issues
in the past
This works for packages build in both Ubuntu and CentOS
Also fix a mistake in the naming for DEBIAN packages, which should be a
no-op since both the DEBIAN and RPM PACKAGE_RELEASE variables are the
same right now
Change-Id: I70659d2e1b6ff9027b8564ca4366d81b0c164760
Signed-off-by: Kent Russell <kent.russell@amd.com>
Don't rely on default values for static/shared sanitizer flags, set them
explicitly based on whether BUILD_SHARED_LIBS is defined or not
Change-Id: Ifbfe95269d1cf184237643176a033a3ce98b62f9
Address-sanitizer doesn't like it at all. And it's called differently
under clang than gcc, so adjust accordingly
Change-Id: Iebe8cd68618d3f7a4c310419c64b4f73d7ecfda4
Move all the logic into 1 spot, and make sure -fsanitize=address is also
passed to the library flags
Change-Id: I7b60629d32df6436b5c7ad37997fe14ea48f5d72
1. add sanitize flag to link flags
2. use ${ADDRESS_SANITIZER} as a condition to turn on/off
instead of (DEFINED ADDRESS_SANITIZER).
The latter will always turn the feature on regardless of
the value as long as there is "-DADDRESS_SANITIZER in
cmake command line,which will be an issue when merging to
the mainline
Amended: put -fsanitize=address at the begining in link flags
Change-Id: I84df0e5b6d7fb8f02f18bf7961f25f15cac10443
Signed-off-by: Gefei Jiang <gefei.jiang@amd.com>
ROCMOPS-1249
correct if statement and -f flag name
Change-Id: I92e9aa30b1c81f855ad269c0c686ec1e136a85fd
Signed-off-by: Gefei Jiang <gefei.jiang@amd.com>
RPM needs _REQUIRES at the end, not _DEPENDS, and also requires a space
before the version of the required package.
Change-Id: I9dd70bd92fc2407b7e8b31e4d46df43c52438a65
Signed-off-by: Kent Russell <kent.russell@amd.com>
Add extended descriptions and e-mail address to CMakeLists
A lintian error will remain regarding stripping the .so, as we
will not be doing this for Release versions of the hsakmt .so
Signed-off-by: Kent Russell <kent.russell@amd.com>
Change-Id: I41c768dee28c0564d92b9c103a6e2d97590e4589
This reverts commit d675d1cce1.
Reason for revert: Change was submitted by accident
Change-Id: If05c705e22296fd3ca789f269737d379a933361d
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Since CMAKE_MODULE_PATH can already be set by another project,
we should just append the libhsamkt cmake module directory to it.
Change-Id: I999dc52a2862e4bbff02e0a8e8b39530f4dae2cd
Signed-off-by: Vlad Sytchenko <vladislav.sytchenko@amd.com>