![]() However, if the call to the llvm_add_library function explicitly specifies a lib type, that type takes precedence over BUILD_SHARED_LIBS, because of this, some libs always get built with a certain link type. CMake seems to default on building the libs as static unless BUILD_SHARED_LIBS is set, in which case it prefers to build them as shared. Note that the usage (actual linking) of these libraries will only occur later by the user of the compiler.Ĭurrently the link type that’s built is primary decided by whether BUILD_SHARED_LIBS is set. whether to build the Flang runtime libraries (which includes FortranDecimal as well) as static or shared.whether we want LLVM libs to be (built and then) linked as shared or static into flang-new (All LLVM libs, including FortranDecimal).We want to separate control over these so that when we are building the compiler we can choose: There is an important distinction between which library link types are built, and which types are linked into what. The goal we are trying to achieve through this patch is to have more control over what link types we are building for the Flang runtime libraries, independently of the link types built and linked into the compiler at build time. ![]() ![]() Also note that libFortranDecimal also gets linked into flang-new when building the compiler, this is a primary reason for this patch. The Phabricator review for this RFC is here: D153426 Support LLVM_BUILD_USER_FORTRAN_LIBS= cmake optionįor this post, assume that “user Fortran libraries” and “Flang runtime libraries” refer to the same thing, the libraries in question are libFortranRuntime and libFortranDecimal, which are the two libraries linked into user executables that we care to be able to control the link type of. ![]()
0 Comments
Leave a Reply. |