Header Files and Library Files

API Types

Generally, an API name is prefixed with acl in the format of acl+ API type abbreviation +*. The asterisk (*) indicates the operation verb and the object, both capitalized. In this document, APIs are referred to as acl APIs.

Table 1 Key API types

API Prefix

Description

acl

Basic APIs, such as initialization & deinitialization, logging, and data type conversion APIs

aclrt

Runtime management APIs, such as device management, stream management, memory management, and kernel loading and execution APIs

aclmdlRI

Model running instance management APIs

acltdt

Data transfer APIs

aclmdl&aclop

Model and operator data dump APIs

aclprof

Profiling APIs

Header Files and Library Files Required by APIs

After installing the firmware, drivers, and the CANN software package, you can reference the header files and library files required by acl APIs when compiling and running your applications.

Include the required header files based on the acl APIs to be called. Refer to the table below for details.

Header files of acl APIs are stored in the ${INSTALL_DIR}/include/ directory, and library files are stored in the ${INSTALL_DIR}/lib64/ directory. Replace ${INSTALL_DIR} with the CANN component directory. For example, if the installation is performed by the root user, the default file storage path is /usr/local/Ascend/cann.

When compiling acl-based applications, link only the library files that correspond to the header files you include. Linking unnecessary library files (such as libascendcl.a) may cause functional issues in the current version or lead to compatibility problems during future upgrades.

Table 2 Runtime header files and library files

Header File

Function

Corresponding Library File

acl/acl_rt.h

Declares APIs for initialization/deinitialization, device management, context management, stream management, synchronization, memory management, and more.

libacl_rt.so

libascendcl.so is used in earlier versions. However, it will no longer be available in later versions. To avoid compatibility issues, you are advised to use libacl_rt.so.

acl/acl_dump.h

Declares model and operator dump APIs.

libascend_dump.so

acl/acl_prof.h

Declares profiling APIs.

libmsprofiler.so

libascendcl.so is used in earlier versions. However, it will no longer be available in later versions. To avoid compatibility issues, you are advised to use libmsprofiler.so.

acl/acl_tdt.h

Declares APIs for tensor data transfer.

libacl_tdt_channel.so

acl/acl_tdt_queue.h

Declares APIs for shared queue management and shared buffer management.

libacl_tdt_queue.so

acl/acl_rt_api.h

Declares C++ extension APIs that provide function overloading and template-based wrappers (for C++ programs only).

It depends on acl_rt.h.

libacl_rt.so

Conventions

In this document, API or parameter status identifiers such as "√" or "Supported", "×" or "Not supported", "Experimental", "Reserved", and "Deprecated" are used. The meanings of these identifiers are as follows:
  • "√" or "Supported": indicates that an API or parameter is supported.
  • "×" or "Not supported": indicates that an API or parameter is not supported. Using such an API or parameter may result in undefined behavior. For example, an error is returned by the API or subsequent service functions are abnormal.
  • "Reserved": indicates that an API or parameter is reserved. Currently, the API or parameter is not implemented or the functionality is not complete and cannot be called. The API or parameter may be available in later versions.
  • "Experimental": indicates that an API or parameter is in the experimental phase. The API definition and behavior may change. You are not advised to use this API or parameter in the production environment.
  • "Deprecated": indicates that an API or parameter is planned to be removed in later versions. You are advised to use the replacement API or parameter provided in this document.