-
Notifications
You must be signed in to change notification settings - Fork 54
Cannot access shared libraries #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Bummer about musl being more difficult than anticipated. I'm not super familiar with AWS lambdas, is accessing shared libraries possible or is static linking the only way forward? It really doesn't matter to me how it happens, but it would be wonderful if I could get rust to talk to a Thanks for your continued help with this! |
One option I could see is to include shared libraries in the build as static files. You would have to change the environment variables/rust configuration to look in that place rather than in the normal locations, but that could be an alternative. Admittedly I don't have a ton of systems knowledge here, so I don't know why diesel requires static links vs. dynamic ones (or maybe that was just the solution for now lambdas). |
Yeah that was just the solution for the lambdas, dynamic links work just fine in other environments. Thanks for the suggestion, I'm going to try that for a while. Bummer that the iteration loop is just so long, compiling for 5 minutes just to get the same error as before is starting to get soul crushing ha. |
@jacobmischka I totally understand that! I've been there many times before. Hopefully #1 will help 😄 |
Hey, that was significantly easier than I thought, thanks so much for your direction. I was able to get it to successfully use the libraries by including a {
"version": 2,
"builds": [
{
"src": "Cargo.toml",
"use": "now-rust",
"config": {
"includeFiles": [
"lib/**",
]
}
}
],
"env": {
"LD_LIBRARY_PATH": "lib/"
},
"build": {
"env": {
"MYSQLCLIENT_LIB_DIR": "lib",
"LD_LIBRARY_PATH": "lib/"
}
}
} |
Wonderful! So glad it worked for you and that we have a nice alternative. I'll add it to the README soon. Thanks for testing! |
* initial rework * add tsconfig * add demo * update Cargo.toml * update README * rename exports * rename exported types, add prettier * 4.0.1-canary.0 * use canary for demo, cleanup * use style guide, cleanup * update README * add more examples * improve examples * polish demos * demo: nextjs, fix layout, use identical seed * runtime: used boxed err * update dep, simplify examples * merged handler example (wip) * Change `impl IntoResponse` into `Response<Body>` (#1) * Rework to allow merging api endpoints * Rework all examples and simplify structure * remove `IntoResponse` --------- Co-authored-by: Florentin / 珞辰 <[email protected]> * dedup body (#2) * dedup body * merge pub use * update docs, use Cargo workspaces * update examples, `0.2.0` * `4.0.0-canary.1` * fix typo * migrate fixtures tests (wip) * migrate fixtures tests - 2 (wip) * migrate fixtures tests - 3 (wip) * add dynamic path example * `4.0.0-canary.2` * migrate fixtures test * add husky * add `.env.example` for cron * add http helpers (#3) * add http helpers * remove opinionated payload * re-add direct crate ref, fix invalid eslint * `4.0.0-canary.3` * `0.2.1` * remove merged example * update README * cleanup workspace members * cleanup * fix newline * rm gitignore from test * `4.0.0.beta.0` --------- Co-authored-by: Douglas Parsons <[email protected]>
I'm using a library that uses pq-sys, which tries to load
libpq
at runtime. Whenever the lambda is invoked, it encounters this error:I'm not familiar with this stuff, but I managed to verify that:
libpq.so.5
is located in/usr/lib64
LD_LIBRARY_PATH
includes/usr/lib64
PQ_LIB_DIR
includes/usr/lib64
It seems the lambda is not able access shared libraries at runtime. Here's an example deployment for reference.
The text was updated successfully, but these errors were encountered: