I use bazel to build a so library using cc_library, and then use cc_binary to deps on it.
but seems bazel change the name of the so library.
below is an example by readelf -d bazel-bin/cyber/mainboard
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libcyber_Slibcyber_Ucore.so]
0x0000000000000001 (NEEDED) Shared library: [libcyber_Sclass_Uloader_Slibclass_Uloader_Umanager.so]
0x0000000000000001 (NEEDED) Shared library: [libcyber_Scomponent_Slibtimer_Ucomponent.so]
0x0000000000000001 (NEEDED) Shared library: [libcyber_Sclass_Uloader_Slibclass_Uloader.so]
0x0000000000000001 (NEEDED) Shared library: [libcyber_Slibinit.so]
0x0000000000000001 (NEEDED) Shared library: [libcyber_Sproto_Slibclock_Uproto.so]
Because I want to export the software and package it as a DEB file, I need more general library files. So my question is how can I change the so library name libcyber_Slibcyber_Ucore.so to libcyber_cyber_core.so? Why bazel use such SONAME rule?
Related
I’m trying to build a Swift Package that wraps a fat static library written in C: libndi_advanced_ios.a from NewTek's Apple Advanced NDI SDK.
I am having trouble linking the pre-compiled library (only headers files and .a binary package is available) to my Swift Package. I have done a lot of research and tried different solutions, but none of them worked. Here is a quick list:
Cannot bundle in an XCFramework because libndi_advanced_ios.a supports multiple platforms (arm_v7, i386, x86_64, arm64) and xcodebuild -create-xcframework return the error binaries with multiple platforms are not supported (this solution is discussed on Swift Forums too);
Using .linkedLibrary in targets as suggested on SPM Documentation (that is outdated) gives the warning system packages are deprecated; use system library targets instead, and I don’t even remember if it builds successfully;
Playing around with different flags and settings (like linkerSettings) has not been successful. Maybe I just missed the right combination.
I can link dozens of Stackoverflow's questions and other posts that didn’t help, but it will be useless (a, b, c).
At the moment I have this configuration:
With Package.swift that contains the following code:
let package = Package(
name: "swift-ndi",
platforms: [.iOS(.v12)],
products: [
.library(
name: "swift-ndi",
targets: ["swift-ndi"])
],
dependencies: [],
targets: [
.target(name: "CiOSNDI", path: "Libraries"),
.target(
name: "swift-ndi",
dependencies: ["CiOSNDI"]),
.testTarget(
name: "swift-ndiTests",
dependencies: ["swift-ndi"]),
]
)
You can find the whole project at alessionossa/swift-ndi.
The only result at the moment are some warnings and the module CiOSNDI do not build:
I tried also .systemLibrary(name: "CiOSNDI", path: "Libraries/"), with this configuration: alessionossa/swift-ndi/tree/systemLibrary; but I get these errors:
NOTE
NDI_include is actually an alias/symbolic link to /Library/NDI Advanced SDK for Apple/include, while NDI_iOS_lib points to /Library/NDI Advanced SDK for Apple/lib/iOS.
I always cleaned build folder after changes to Package.swift.
UPDATE 10/01/2022: libndi_advanced_ios.a requires libc++.tbd. That can be easy linked in an app in Build Phases -> Link Binary With Libraries, but I don’t know how to link in a Swift Package.
Binary targets need to specified with .binary_target. See the docs and example here.
An example of a static library wrapped in an .xcframework looks like this from the file command:
$ file GoogleAppMeasurement.xcframework/ios-arm64_armv7/GoogleAppMeasurement.framework/GoogleAppMeasurement
GoogleAppMeasurement.xcframework/ios-arm64_armv7/GoogleAppMeasurement.framework/GoogleAppMeasurement: Mach-O universal binary with 2 architectures: [arm_v7:current ar archive] [arm64]
GoogleAppMeasurement.xcframework/ios-arm64_armv7/GoogleAppMeasurement.framework/GoogleAppMeasurement (for architecture armv7): current ar archive
GoogleAppMeasurement.xcframework/ios-arm64_armv7/GoogleAppMeasurement.framework/GoogleAppMeasurement (for architecture arm64): current ar archive
One way to create the .xcframework file is to use Firebase's ZipBuilder that creates a .xcframework files from static libraries that are specified with a CocoaPods podspec file.
I also needed to add the NDI SDK as a Swift package dependency in my app.
I found a couple of approaches that worked:
You can create an XCFramework bundle by extracting a thin arm64 library from the universal library:
lipo "/Library/NDI SDK for Apple/lib/iOS/libndi_ios.a" -thin arm64 -output "$STAGING_DIRECTORY/libndi.a"
Then create an XCFramework bundle:
xcodebuild -create-xcframework -library "$STAGING_DIRECTORY/libndi.a" -headers "/Library/NDI SDK for Apple/include" -output "$STAGING_DIRECTORY/Clibndi.xcframework"
I ended up not using this approach because hosting the XCFramework as a downloadable binary release on GitHub required me to make my repo public (see this issue).
Instead I am using a system library target, in my Package.swift:
targets: [
.target(
name: "WrapperLibrary",
dependencies: ["Clibndi"],
linkerSettings: [
.linkedFramework("Accelerate"),
.linkedFramework("VideoToolbox"),
.linkedLibrary("c++")
]),
.systemLibrary(name: "Clibndi")
]
Then, I have WrapperLibrary/Sources/Clibndi/module.modulemap that looks like:
module Clibndi {
header "/Library/NDI SDK for Apple/include/Processing.NDI.Lib.h"
link "ndi_ios"
export *
}
Finally, my application target (part of an Xcode project, not a Swift package) depends on WrapperLibrary, and I had to add "/Library/NDI SDK for Apple/lib/iOS" (including the quotation marks) to "Library Search Paths" in the "Build Settings" tab.
As an alternative to modifying the application target build settings, you could add a pkg-config file to a directory in your pkg-config search paths. For example, /usr/local/lib/pkgconfig/libndi_ios.pc:
NDI_SDK_ROOT=/Library/NDI\ SDK\ for\ Apple
Name: NDI SDK for iOS
Description: The NDI SDK for iOS
Version: 5.1.1
Cflags: -I${NDI_SDK_ROOT}/include
Libs: -L${NDI_SDK_ROOT}/lib/iOS -lndi_ios
Then use .systemLibrary(name: "Clibndi", pkgconfig: "libndi_ios") in your package manifest. I found this less convenient for users than just adding the setting to my application target, however.
Ideally you could add the NDI SDK's dependency library and frameworks to the pkg-config file as well (Libs: -L${NDI_SDK_ROOT}/lib/iOS -lndi_ios -lc++ -framework Accelerate -framework VideoToolbox), but it appears there is a bug in Swift's pkg-config parsing of -framework arguments, so I filed a bug: SR-15933.
In RAD Studio installation directory (e.g.: C:\Program Files (x86)\Embarcadero\Studio\21.0), there is a Redist contains some *.redistlist files:
c:\> dir "C:\Program Files (x86)\Embarcadero\Studio\21.0\redist\*.redistlist"
Volume in drive S is RAD Studio 10.4.2
Volume Serial Number is 026F-0E48
Directory of C:\Program Files (x86)\Embarcadero\Studio\21.0\Redist
20/02/2021 07:55 AM 67 iossimulator.redistlist
20/02/2021 07:55 AM 1,384 linux64.redistlist
20/02/2021 07:55 AM 2,273 osx32.redistlist
20/02/2021 07:55 AM 2,100 osx64.redistlist
20/02/2021 07:55 AM 3,363 win32.redistlist
20/02/2021 07:55 AM 2,939 win64.redistlist
6 File(s) 12,126 bytes
The content of the redistlist file is a list of runtime packages filename. What is the purpose of the redistlist file? Can it be utilized for deployment task? Or it simply record available runtime packages only?
I am trying to compile a project that depends on PCL and OpenCV.
The CMakeLists.txt looks like:
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(pcl_visualizer_viewports)
find_package(PCL 1.2 REQUIRED)
find_package(OpenCV REQUIRED)
message("this is my message " ${OpenCV_LIBRARIES} )
message("this is my message " ${OpenCV_INCLUDE_DIRS} )
message("this is my message " ${OpenCV_INSTALL_PATH} )
include_directories(${PCL_INCLUDE_DIRS} ${OpenCV_INCLUDE_DIRS})
link_directories(${PCL_LIBRARY_DIRS})
add_definitions(${PCL_DEFINITIONS})
add_executable (pcl_visualizer_demo pcl_visualizer_demo.cpp readInputFile.cpp readInputFile.h defines.h helper.cpp helper.h Image_Safety.h Image_Safety.cpp)
target_link_libraries (pcl_visualizer_demo ${PCL_LIBRARIES} ${OpenCV_LIBRARIES})
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
The result is however a segmentation fault and core dumped. I have read through the Cmake tutorial, but I have not found the issue. CMake generates the object files for all:
Scanning dependencies of target pcl_visualizer_demo
[ 20%] Building CXX object CMakeFiles/pcl_visualizer_demo.dir/Image_Safety.cpp.o
[ 40%] Building CXX object CMakeFiles/pcl_visualizer_demo.dir/helper.cpp.o
[ 60%] Building CXX object CMakeFiles/pcl_visualizer_demo.dir/image_converter.cpp.o
[ 80%] Building CXX object CMakeFiles/pcl_visualizer_demo.dir/readInputFile.cpp.o
[100%] Building CXX object CMakeFiles/pcl_visualizer_demo.dir/pcl_visualizer_demo.cpp.o
Linking CXX executable pcl_visualizer_demo
Looking at the linking verbose information, the different object files are mentioned and I interpret this as they are linked.
What am I missing?
update
Weird so the error occurs in some part of the code using basic opencv functions cv::waitKey and cv::imshow, it may seem to be an issue with QT according to this and this.
I had a similar issue. In the end I had to build PCL without QT (I also found several posts which stated interference, but found no solution)
I'm having trouble creating a swift static library which uses external cocoa pods libraries (SSZipArchive).
I'm getting the following error:
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: unknown option character `X' in: -Xlinker
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] [-no_warning_for_no_symbols]
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
I have no clue why is this happening.
You cannot create static Swift libraries.
It was a 'bug' but then the Apple engineers decided to state this is intended behaviour. I needed to make static libraries myself and I am currently SOL on it.
Xcode does not support building static libraries that include Swift code.
#Aggressor is correct about the current state of affairs, but even if (when) Swift does allow the creation of static libraries, you must not do this. Third-party libraries must never be incorporated into a static library. This leads to all kinds of build conflicts later if the consumer also includes those libraries (or if another static library does). For more information (and links to even more information), see this ObjC version of the question. If Swift ever supports this, it will be the same issue. The final executable should link together all your libraries.
I am trying to reverse engineer a previous employee's build process for some custom software he wrote for us. I've seen to get everything to compile okay, but I get an error in the linking process that points to a problem with crypto++. Any clues?
compile.util:
compile:
[echo] Compiling: util
[cc] Starting dependency analysis for 55 files.
[cc] 55 files are up to date.
[cc] 0 files to be recompiled from dependency analysis.
[cc] 0 total files to be compiled.
link.util:
link:
[echo] Linking shared library: libutil
[cc] 0 total files to be compiled.
[cc] Starting link
[cc] /usr/bin/ld: /home/john/softwarename/thirdparty/crypto/5.6.1_64/libcryptopp.a(cryptlib.o): relocation R_X86_64_32 against `CryptoPP::DEFAULT_CHANNEL' can not be used when making a shared object; recompile with -fPIC
[cc] /home/john/softwarename/thirdparty/crypto/5.6.1_64/libcryptopp.a: could not read symbols: Bad value
[cc] collect2: ld returned 1 exit status
BUILD FAILED
/home/john/softwarename/build/build.xml:167: Following error occured while executing this line
/home/john/softwarename/build/link.xml:27: gcc failed with return code 1
Os is Fedora 11
Every object file you link into a shared library must be position independent, meaning the loader can move it wherever it wants in memory and it will still work. Your crypto library was not compiled that way, hence the admonition to recompile it with -fPIC added to your compile flags. Alternately, you can make libutil a static library instead of a shared one. Without more details on your build files, I can't provide more details on how to do that or which one to choose.