I'm getting this error:
If you want to include a polyfill, you need to: - add a fallback 'resolve.fallback: { "path": require.resolve("path-browserify") }' - install 'path-browserify' :
(base) raphy#pc:~/NEW-Raphy-Template$ yarn start
yarn run v1.22.18
$ yarn run build && ELECTRON_DISABLE_SECURITY_WARNINGS=true electron ./dist/main/main.js
$ npx webpack --config ./webpack.config.js
asset main.js 11.2 MiB [compared for emit] (name: main)
runtime modules 793 bytes 4 modules
javascript modules 8.33 MiB
modules by path ./node_modules/ 8.26 MiB
cacheable modules 8.26 MiB 1402 modules
optional modules 3.24 KiB [optional] 3 modules
modules by path ./src/ 74.6 KiB 18 modules
+ 28 modules
json modules 1.19 MiB
modules by path ./node_modules/har-schema/lib/ 6.93 KiB 18 modules
modules by path ./node_modules/cheerio/ 96.9 KiB 16 modules
modules by path ./node_modules/#postlight/mercury-parser/ 261 KiB 9 modules
modules by path ./node_modules/iconv-lite/ 86.7 KiB 8 modules
modules by path ./node_modules/ajv/lib/ 5.58 KiB 3 modules
modules by path ./node_modules/whatwg-encoding/lib/ 5.33 KiB 2 modules
+ 7 modules
WARNING in ./node_modules/jsdom/lib/jsdom/utils.js 186:21-40
Critical dependency: the request of a dependency is an expression
# ./node_modules/jsdom/lib/jsdom/browser/Window.js 8:26-45
# ./node_modules/jsdom/lib/api.js 14:15-51
# ./node_modules/turndown/lib/turndown.es.js 527:16-38
# ./node_modules/#postlight/mercury-parser/dist/mercury.js 11:38-57
# ./src/main/main.ts 54:41-77
WARNING in ./node_modules/parse5/lib/index.js 55:23-49
Critical dependency: the request of a dependency is an expression
# ./node_modules/jsdom/lib/jsdom/browser/domtohtml.js 2:15-32
# ./node_modules/jsdom/lib/api.js 15:22-61
# ./node_modules/turndown/lib/turndown.es.js 527:16-38
# ./node_modules/#postlight/mercury-parser/dist/mercury.js 11:38-57
# ./src/main/main.ts 54:41-77
2 warnings have detailed information that is not shown.
Use 'stats.errorDetails: true' resp. '--stats-error-details' to show it.
webpack 5.72.1 compiled with 2 warnings in 23433 ms
assets by path assets/css/ 1.25 MiB
assets by path assets/css/fonts/ 1.19 MiB 13 assets
assets by path assets/css/*.css 45.9 KiB 9 assets
assets by path assets/css/images/*.png 6.35 KiB
asset assets/css/images/marker-icon-2x.png 2.41 KiB [compared for emit] [from: src/assets/css/images/marker-icon-2x.png] [copied]
+ 4 assets
asset assets/css/App.scss 5.26 KiB [compared for emit] [from: src/assets/css/App.scss] [copied]
asset assets/css/postcss/app.pcss 721 bytes [compared for emit] [from: src/assets/css/postcss/app.pcss] [copied]
assets by path *.js 5.66 MiB
asset app.js 5.66 MiB [compared for emit] (name: app)
asset style.js 2.72 KiB [compared for emit] (name: style)
assets by path *.css 79.3 KiB
asset app.css 41.5 KiB [compared for emit] (name: app)
asset style.css 37.8 KiB [compared for emit] (name: style)
asset index.html 617 bytes [compared for emit]
Entrypoint app 5.7 MiB = app.css 41.5 KiB app.js 5.66 MiB
Entrypoint style 40.5 KiB = style.css 37.8 KiB style.js 2.72 KiB
orphan modules 286 KiB [orphan] 159 modules
runtime modules 1.59 KiB 7 modules
modules by path ./node_modules/ 3.87 MiB (javascript) 18.3 KiB (css/mini-extract) 1599 modules
modules by path ./src/ 39.1 KiB (javascript) 41.5 KiB (css/mini-extract)
javascript modules 39.1 KiB
modules by path ./src/app/ 35.3 KiB 14 modules
+ 4 modules
css modules 41.5 KiB
modules by path ./src/app/sections/ 1.43 KiB 2 modules
css ./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/app/styles/index.css 19.5 KiB [built] [code generated]
css ./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/assets/css/global.css 19.7 KiB [built] [code generated]
css ./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/app/components/Sidebar.css 940 bytes [built] [code generated]
ERROR in ./node_modules/file-url/index.js 2:13-28
Module not found: Error: Can't resolve 'path' in '/home/raphy/NEW-Raphy-Template/node_modules/file-url'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "path": require.resolve("path-browserify") }'
- install 'path-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "path": false }
resolve 'path' in '/home/raphy/NEW-Raphy-Template/node_modules/file-url'
Parsed request is a module
using description file: /home/raphy/NEW-Raphy-Template/node_modules/file-url/package.json (relative path: .)
Field 'browser' doesn't contain a valid alias configuration
resolve as module
/home/raphy/NEW-Raphy-Template/node_modules/file-url/node_modules doesn't exist or is not a directory
/home/raphy/NEW-Raphy-Template/node_modules/node_modules doesn't exist or is not a directory
looking for modules in /home/raphy/NEW-Raphy-Template/node_modules
single file module
using description file: /home/raphy/NEW-Raphy-Template/package.json (relative path: ./node_modules/path)
no extension
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path doesn't exist
.jsx
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path.jsx doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path.js doesn't exist
.tsx
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path.tsx doesn't exist
.ts
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path.ts doesn't exist
/home/raphy/NEW-Raphy-Template/node_modules/path doesn't exist
looking for modules in /home/raphy/node_modules
single file module
No description file found in /home/raphy/node_modules or above
no extension
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path doesn't exist
.jsx
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path.jsx doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path.js doesn't exist
.tsx
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path.tsx doesn't exist
.ts
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path.ts doesn't exist
/home/raphy/node_modules/path doesn't exist
/home/node_modules doesn't exist or is not a directory
/node_modules doesn't exist or is not a directory
# ./src/app/sections/infobasket/Infobasket.js 83:16-35
# ./src/app/components/App.tsx 18:41-85
# ./src/app/index.tsx 7:34-61
webpack 5.72.1 compiled with 1 error in 23411 ms
But if I add those fallback in resolve :
// main process
var main_config = {
mode: isEnvProduction ? 'production' : 'development',
entry: './src/main/main.ts',
target: 'electron-main',
resolve: {
fallback: { 'path': require.resolve('path-browserify') },
extensions: ['.jsx', '.js', 'ts'],
},
I get the same kind of error:
(base) raphy#pc:~/NEW-Raphy-Template$ yarn start
yarn run v1.22.18
$ yarn run build && ELECTRON_DISABLE_SECURITY_WARNINGS=true electron ./dist/main/main.js
$ npx webpack --config ./webpack.config.js
asset main.js 11.2 MiB [compared for emit] (name: main)
runtime modules 793 bytes 4 modules
javascript modules 8.33 MiB
modules by path ./node_modules/ 8.26 MiB
cacheable modules 8.26 MiB 1402 modules
optional modules 3.24 KiB [optional] 3 modules
modules by path ./src/ 74.6 KiB 18 modules
+ 28 modules
json modules 1.19 MiB
modules by path ./node_modules/har-schema/lib/ 6.93 KiB 18 modules
modules by path ./node_modules/cheerio/ 96.9 KiB 16 modules
modules by path ./node_modules/#postlight/mercury-parser/ 261 KiB 9 modules
modules by path ./node_modules/iconv-lite/ 86.7 KiB 8 modules
modules by path ./node_modules/ajv/lib/ 5.58 KiB 3 modules
modules by path ./node_modules/whatwg-encoding/lib/ 5.33 KiB 2 modules
+ 7 modules
WARNING in ./node_modules/jsdom/lib/jsdom/utils.js 186:21-40
Critical dependency: the request of a dependency is an expression
# ./node_modules/jsdom/lib/jsdom/browser/Window.js 8:26-45
# ./node_modules/jsdom/lib/api.js 14:15-51
# ./node_modules/turndown/lib/turndown.es.js 527:16-38
# ./node_modules/#postlight/mercury-parser/dist/mercury.js 11:38-57
# ./src/main/main.ts 54:41-77
WARNING in ./node_modules/parse5/lib/index.js 55:23-49
Critical dependency: the request of a dependency is an expression
# ./node_modules/jsdom/lib/jsdom/browser/domtohtml.js 2:15-32
# ./node_modules/jsdom/lib/api.js 15:22-61
# ./node_modules/turndown/lib/turndown.es.js 527:16-38
# ./node_modules/#postlight/mercury-parser/dist/mercury.js 11:38-57
# ./src/main/main.ts 54:41-77
2 warnings have detailed information that is not shown.
Use 'stats.errorDetails: true' resp. '--stats-error-details' to show it.
webpack 5.72.1 compiled with 2 warnings in 23467 ms
assets by path assets/css/ 1.25 MiB
assets by path assets/css/fonts/ 1.19 MiB 13 assets
assets by path assets/css/*.css 45.9 KiB 9 assets
assets by path assets/css/images/*.png 6.35 KiB
asset assets/css/images/marker-icon-2x.png 2.41 KiB [compared for emit] [from: src/assets/css/images/marker-icon-2x.png] [copied]
+ 4 assets
asset assets/css/App.scss 5.26 KiB [compared for emit] [from: src/assets/css/App.scss] [copied]
asset assets/css/postcss/app.pcss 721 bytes [compared for emit] [from: src/assets/css/postcss/app.pcss] [copied]
assets by path *.js 5.66 MiB
asset app.js 5.66 MiB [compared for emit] (name: app)
asset style.js 2.72 KiB [compared for emit] (name: style)
assets by path *.css 79.3 KiB
asset app.css 41.5 KiB [compared for emit] (name: app)
asset style.css 37.8 KiB [compared for emit] (name: style)
asset index.html 617 bytes [compared for emit]
Entrypoint app 5.7 MiB = app.css 41.5 KiB app.js 5.66 MiB
Entrypoint style 40.5 KiB = style.css 37.8 KiB style.js 2.72 KiB
orphan modules 286 KiB [orphan] 159 modules
runtime modules 1.59 KiB 7 modules
modules by path ./node_modules/ 3.87 MiB (javascript) 18.3 KiB (css/mini-extract) 1599 modules
modules by path ./src/ 39.1 KiB (javascript) 41.5 KiB (css/mini-extract)
javascript modules 39.1 KiB
modules by path ./src/app/ 35.3 KiB 14 modules
+ 4 modules
css modules 41.5 KiB
modules by path ./src/app/sections/ 1.43 KiB 2 modules
css ./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/app/styles/index.css 19.5 KiB [built] [code generated]
css ./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/assets/css/global.css 19.7 KiB [built] [code generated]
css ./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/app/components/Sidebar.css 940 bytes [built] [code generated]
ERROR in ./node_modules/file-url/index.js 2:13-28
Module not found: Error: Can't resolve 'path' in '/home/raphy/NEW-Raphy-Template/node_modules/file-url'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "path": require.resolve("path-browserify") }'
- install 'path-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "path": false }
resolve 'path' in '/home/raphy/NEW-Raphy-Template/node_modules/file-url'
Parsed request is a module
using description file: /home/raphy/NEW-Raphy-Template/node_modules/file-url/package.json (relative path: .)
Field 'browser' doesn't contain a valid alias configuration
resolve as module
/home/raphy/NEW-Raphy-Template/node_modules/file-url/node_modules doesn't exist or is not a directory
/home/raphy/NEW-Raphy-Template/node_modules/node_modules doesn't exist or is not a directory
looking for modules in /home/raphy/NEW-Raphy-Template/node_modules
single file module
using description file: /home/raphy/NEW-Raphy-Template/package.json (relative path: ./node_modules/path)
no extension
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path doesn't exist
.jsx
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path.jsx doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path.js doesn't exist
.tsx
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path.tsx doesn't exist
.ts
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/NEW-Raphy-Template/node_modules/path.ts doesn't exist
/home/raphy/NEW-Raphy-Template/node_modules/path doesn't exist
looking for modules in /home/raphy/node_modules
single file module
No description file found in /home/raphy/node_modules or above
no extension
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path doesn't exist
.jsx
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path.jsx doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path.js doesn't exist
.tsx
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path.tsx doesn't exist
.ts
Field 'browser' doesn't contain a valid alias configuration
/home/raphy/node_modules/path.ts doesn't exist
/home/raphy/node_modules/path doesn't exist
/home/node_modules doesn't exist or is not a directory
/node_modules doesn't exist or is not a directory
# ./src/app/sections/infobasket/Infobasket.js 83:16-35
# ./src/app/components/App.tsx 18:41-85
# ./src/app/index.tsx 7:34-61
webpack 5.72.1 compiled with 1 error in 23445 ms
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
So.... How to correctly resolve in webpack.config.js ?
SOLVED.
Just adding
resolve: {
fallback: { 'path': require.resolve('path-browserify') },
extensions: ['.jsx', '.js', '.tsx', '.ts'],
}
also in the renderer part of the webpack configuration
It worked for me
adding more clarity to those who are not able to understand the above quoted inputs
Using
"react": "^18.2.0",
"react-scripts": "5.0.1",
Follow these steps:
yarn add path-browserify
Go to node_modules and look for react-scripts [as shown in the image below 2.a & 2.b (look for webpack.config.js); then search for resolve: in the webpack.config.js file and add this line (as seen in 2.c) {fallback:{path : require.resolve("path-browserify")}
]
save the file
go the code where you had set the path.. comment and update as shown in the below image
stop the application
run yarn cache clean
run yarn start .. it should work now
Related
When I run a program with CLion, I have the below directories and files generated automatically except Problem Details.txt
Mode LastWriteTime Length Name
---------------------------
d----- 10/1/2022 3:48 PM .idea
d----- 10/1/2022 3:48 PM cmake-build-debug
-a---- 5/1/2022 1:42 AM 116 CMakeLists.txt
-a---- 6/14/2022 4:03 PM 1106 main.cpp
-a---- 1/3/2022 2:33 PM 155 Probelem Details.txt
I'm not sure which files I should put into the .gitignore file while I'm pushing this local repo to any remote repo.
I tried to push all the files and folders to the remote repo but it showed me few warnings!
CLion creates a .idea folder which keeps your project settings and cmake-build-... which is where your executables build depending on your build configuration. Those are not needed since in an online repo you'd only want the cmake project and your source code. Adding these in the .gitignore is enough.
# CLion project files
.idea
cmake-build-*
I'm trying to run some tensorflow-recommenders code on an AWS EMR cluster.
My testing Spark cluster has a g3.4xlarge master node and a few g3.4xlarge core nodes.
I have a bootstrap action which does the following:
sudo yum -y install cudatoolkit
sudo yum -y install nvidia
At runtime however it appears that some of the cudatoolkit libs aren't found:
Not creating XLA devices, tf_xla_enable_xla_devices not set
Successfully opened dynamic library libcuda.so.1
I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:941] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
I tensorflow/core/common_runtime/gpu/gpu_device.cc:1720] Found device 0 with properties:
pciBusID: 0000:00:1e.0 name: Tesla M60 computeCapability: 5.2
coreClock: 1.1775GHz coreCount: 16 deviceMemorySize: 7.44GiB deviceMemoryBandwidth: 149.31GiB/s
W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcudart.so.11.0'; dlerror: libcudart.so.11.0: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcublas.so.11'; dlerror: libcublas.so.11: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcublasLt.so.11'; dlerror: libcublasLt.so.11: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcufft.so.10
I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcurand.so.10
I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcusolver.so.10
W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcusparse.so.11'; dlerror: libcusparse.so.11: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcudnn.so.8'; dlerror: libcudnn.so.8: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
W tensorflow/core/common_runtime/gpu/gpu_device.cc:1757] Cannot dlopen some GPU libraries. Please make sure the missing libraries mentioned above are installed properly if you would like to use GPU. Follow the guide at https://www.tensorflow.org/install/gpu for how to download and setup the required libraries for your platform.
Would I need to augment the LD_LIBRARY_PATH within my bootstrap action? I'd worry about it taking effect without a reboot and I'd worry about trying to reboot from within a bootstrap action.
Has anyone else come across this type of problem? Any recommendations? Thanks.
I am using CMake to compile an executable that is linked against several libraries that I have built and installed into a local project directory (libs/3rdparty). Note that this is prior to installation of the project, primarily for the purpose of running unit tests and debugging. The problem I am having is that sometimes there is a library that is linked, but the executable is missing the path to the library. The library I am currently having an issue with is leptonica. However, I have run into this issue several times with different libraries on different platforms (osx, fedora, centos, ubuntu). Through research I have seen similar issues, but I have never been able to find a definitive answer of why the full path to the library would be missing.
I've tried playing with:
CMAKE_BUILD_WITH_INSTALL_RPATH
CMAKE_INSTALL_RPATH
CMAKE_INSTALL_RPATH_USE_LINK_PATH
and these don't seem to have much effect.
My CMakeLists contains:
find_package(Leptonica REQUIRED)
target_link_libraries(${target}
PRIVATE
...
${Leptonica_LIBRARIES}
)
Here is the output from ldd on one of the unit test executables:
ldd test_utilities
...
libleptonica.so.5.3.0 => not found
libtesseract.so.4 => {MY PROJECT}/libs/3rdparty/tesseract/lib/libtesseract.so.4
leptonica is the only library that is not found out of ~30 other libraries.
Does anyone know what the root cause of this problem is? I am not looking to work around the problem by modifying LD_LIBRARY_PATH.
-- Added LeptonicaTargets-release.cmake. According to this the full path to the lib should be in the target.
#----------------------------------------------------------------
# Generated CMake target import file for configuration "RELEASE".
#----------------------------------------------------------------
# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)
# Import target "leptonica" for configuration "RELEASE"
set_property(TARGET leptonica APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(leptonica PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "/usr/lib/x86_64-linux-gnu/libpng.so;/usr/lib/x86_64-linux-gnu/libz.so;m"
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libleptonica.so.1.77.0"
IMPORTED_SONAME_RELEASE "libleptonica.so.5.3.0"
)
list(APPEND _IMPORT_CHECK_TARGETS leptonica )
list(APPEND _IMPORT_CHECK_FILES_FOR_leptonica "${_IMPORT_PREFIX}/lib/libleptonica.so.1.77.0" )
# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)
Here are the files in the leptonica/lib directory:
ll libs/3rdparty/leptonica/lib/
total 2776
drwxr-xr-x 3 user user 4096 May 30 14:17 ./
drwxr-xr-x 5 user user 4096 May 30 14:17 ../
lrwxrwxrwx 1 user user 21 May 30 14:17 libleptonica.so -> libleptonica.so.5.3.0
-rw-r--r-- 1 user user 2829784 May 30 09:49 libleptonica.so.1.77.0
lrwxrwxrwx 1 user user 22 May 30 14:17 libleptonica.so.5.3.0 -> libleptonica.so.1.77.0
drwxr-xr-x 2 user user 4096 May 30 14:17 pkgconfig/
Output from chrpath --list test_utilities appears to contain the correct path to the library as well:
chrpath --list test_utilities
test_utilities: RUNPATH=...:{MY PROJECT}/libs/3rdparty/leptonica/lib:...
For anyone who runs across this, I have finally figured it out.
The issue was related to the library being a transitive dependency of OpenCV. On Ubuntu, ld now defaults to using using --enable-new-dtags which uses RUNPATH, not RPATH. There is an issue where RUNPATH is not searched for transitive dependencies.
See https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638
Simply adding "-Wl,--disable-new-dtags" to the target linker options resolved my issue. All libraries are now found, including other libraries than leptonica that I added today. I am sure that I will likely have to make changes when building a package for installation though.
I've built some boost libraries (particularly system and serialization) with the _GLIBCXX_USE_CXX11_ABI=0 macro (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html) due to the fact that I'm using boost::asio to share information (by mean) between my code and an old application (Webots 7.4.3, pre GCC-5). However, I already have standard boost libraries installed in my system (required by several other applications). I've opted to install the custom-compiled versions to /usr/local/lib (while the default versions are kept in /usr/lib) and renamed the libraries with the suffix _oldabi:
$ ls -lash /usr/local/lib | grep boost
1,1M -rw-r--r-- 1 root root 1,1M jun 21 14:17 libboost_serialization_oldabi.a
416K -rw-r--r-- 2 root root 415K jun 21 14:17 libboost_serialization_oldabi.so
416K -rw-r--r-- 2 root root 415K jun 21 14:17 libboost_serialization_oldabi.so.1.64.0
0 lrwxrwxrwx 1 root root 39 jun 21 14:18 libboost_serialization.so.1.64.0 -> libboost_serialization_oldabi.so.1.64.0
48K -rw-r--r-- 1 root root 46K jun 21 14:17 libboost_system_oldabi.a
20K -rw-r--r-- 2 root root 20K jun 21 14:17 libboost_system_oldabi.so
20K -rw-r--r-- 2 root root 20K jun 21 14:17 libboost_system_oldabi.so.1.64.0
0 lrwxrwxrwx 1 root root 32 jun 21 14:18 libboost_system.so.1.64.0 -> libboost_system_oldabi.so.1.64.0
708K -rw-r--r-- 1 root root 706K jun 21 14:17 libboost_wserialization_oldabi.a
300K -rw-r--r-- 2 root root 299K jun 21 14:17 libboost_wserialization_oldabi.so
300K -rw-r--r-- 2 root root 299K jun 21 14:17 libboost_wserialization_oldabi.so.1.64.0
0 lrwxrwxrwx 1 root root 40 jun 21 14:18 libboost_wserialization.so.1.64.0 -> libboost_wserialization_oldabi.so.1.64.0
The code works well, socket communications work as intended. However, when trying to set up the code on another computer without the default boost libraries installed (only custom-compiled versions of boost::system and boost::serialization), I get (system:9) Bad file descriptor when performing write/read operations. While trying to figure out the problem, I went back for the original computer and by looking at /proc/XXXX/maps I noticed that my executable was actually loading the default boost libraries under /usr/lib at runtime, despite being linked with the custom-built versions at compilation.
Thus my issues are 1) how to make the system prioritize /usr/local/lib over /usr/lib or force it to identify the _boost_oldabi suffix as different libraries; and 2) figure out why does adding the GCC ABI macro seems to break the code; The source code, make files and libraries are exactly the same, the only thing that differs between the computers is the OS (Arch Linux and Ubuntu).
Preamble: If you need your custom boost libraries only for a single tool, it is better to install them into a place which is specific to this single tool. Installing custom libs into a system-wide location (/usr/local/lib) is not a very good idea, because
It increases the risk that also your system-wide apps will use the bad one.
If you want once cleanup /usr/local/lib, you won't be able to know, what is using the libs there.
It would be better if you would make them available only for your software. For example, if your software is in /srv/niceproject/bin, then the libs could exist in /srv/niceproject/lib.
Note, the shared library handling is enough smart in Linux to handle libraries with different versions available, all the binaries will map in the libs according to their needed versions. But, it depends on special symbols inserted by the linker into the binaries. If you change only the compiler flags, these symbols may be the same, thus a false lib may be linked in.
You can prioritize /usr/local/lib by changing the shared library order in /etc/ld.so.conf and in /etc/ld.so.conf.d, and then calling an ldconfig. To get the list of the currently visible libraries, use ldconfig -p.
There is a lot, so an ldconfig -p|grep libboost could be a nicer result.
The shared library directory order is affected also by the LD_LIBRARY_PATH environment variable, what can be specified for every process. Thus, calling your tool with
LD_LIBRARY_PATH=/srv/niceproject/lib /srv/niceproject/bin/mytool
will call mytool on a way, that it tries to find the libs in /srv/niceproject/lib first, and looks the system-wide ones only after it. It is a colon-separated list of pathes, like $PATH.
Linking your binary with a library given by an absolute path will hardcode the absolute path into the library. So:
gcc -o mytool -l/usr/local/lib/libboost_oldapi_anything.so
Also this is a dirty solution in general, but it would solve your problem.
You can see, what exactly an actual library is loading, with the ldd tool:
# ldd /bin/bash
linux-vdso.so.1 => (0x00007ffd1c1cf000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f4baa499000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4baa295000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4ba9eca000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4baa6d0000)
ldd is a special binary, you can specify any LD_LIBRARY_PATH, it won't affect it (but it will affect the binary you are checking with it). In my example, with an LD_LIBRARY_PATH=/srv/niceproject/lib ldd /srv/niceproject/bin/mytool will show, how the mytool is affected by this environment variable.
I'm running Ubuntu 13.10 . I installed libboost1.54-dev.
I did a Git checkout of Boost, and did a checkout to "boost-1.54.0".
I changed directories to boost/libs/python/example/tutorial in the source.
I ran "bjam". I get:
$ bjam
Unable to load Boost.Build: could not find build system.
---------------------------------------------------------
/home/dustin/build/boost/libs/python/example/boost-build.jam attempted to load the build system by invoking
'boost-build ../../../tools/build/v2 ;'
but we were unable to find "bootstrap.jam" in the specified directory
or in BOOST_BUILD_PATH (searching /home/dustin/build/boost/libs/python/example/../../../tools/build/v2, /usr/share/boost-build).
Please consult the documentation at 'http://www.boost.org'.
There are only three files in the example directory:
-rw-r--r-- 1 dustin dustin 484 Mar 1 12:59 hello.cpp
-rwxr-xr-x 1 dustin dustin 275 Mar 1 12:59 hello.py
-rw-r--r-- 1 dustin dustin 1445 Mar 1 15:43 Jamroot
The directions say that it should be just that easy: http://www.boost.org/doc/libs/1_54_0/libs/python/doc/tutorial/doc/html/python/hello.html
The last few lines of the strace is:
openat(AT_FDCWD, "/home/dustin/build/boost/libs/python/example/tutorial", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/home/dustin/build/boost/libs/python/example", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/share/boost-build", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/dustin/build/boost/libs/python/example/boost-build.jam", O_RDONLY) = 3
Why is it looking for boost-build.jam? What am I missing?
You can create your own boost-build.jam. For quickstart example (which is broke) just create a file called boost-build.jam with this in it and make sure it points to the src directory. It is discussed here http://lists.boost.org/boost-build/2014/11/27738.php
# Edit this path to point at the tools/build/v2 subdirectory of your
# Boost installation. Absolute paths work, too.
boost-build ../../../../tools/build/src ;
In essence, bjam is an interpreter, and Boost.Build is a build system written in bjam files. When bjam starts, it will attempt to locate the jam files for Boost.Build. In this case, bjam attempted to locate boost-build.jam relative to the tutorial and errors when it is missing. To build the tutorial, either:
Verify that the boost/tools/build submodule has been initialized from within the boost git repository. Boost.Python has other dependencies, so it may be easier to initialize all submodules. This will allow the bjam interpreter installed from the libboost1.54-dev package to locate Boost.Build from within the repository, and build the tutorial and its dependencies.
To build against packaged libraries:
Install the libboost1.54 package. This will install the Boost.Python shared library and its dependencies.
Modify the tutorial's Jamroot file. It should no longer attempt to use the boost project, and should explicitly list the Boost.Python shared library path:
-# Specify the path to the Boost project. If you move this project,
-# adjust this path to refer to the Boost root directory.
-use-project boost
- : ../../../.. ;
-
# Set up the project-wide requirements that everything uses the
-# boost_python library from the project whose global ID is
-# /boost/python.
+# boost_python library.
project
- : requirements <library>/boost/python//boost_python ;
+ : requirements <library>/usr/lib/libboost_python-py27.so ;
The library path and name may need to be changed based on where the libboost-python1.54-dev packaged installed the Boost.Python library.
Set the BOOST_BUILD_PATH environment variable to /usr/share/boost-build/kernel or wherever the libboost1.54-dev package installed boost-build.jam.