#Shared library referencing another

1 messages · Page 1 of 1 (latest)

winged dune
#

I'm having an issue with a shared library referencing another even though i linked one with the other with linkLibrary.

dlopen(/Users/giann/git/buzz/dist/lib/libos.dylib, 0x0001): Library not loaded: '@rpath/libbuzz.dylib'
  Referenced from: '/Users/giann/git/buzz/dist/lib/libos.dylib'
  Reason: tried: 'dist/lib/libbuzz.dylib' (no such file), 'dist/lib/libbuzz.dylib' (no such file), '/usr/local/lib/libbuzz.dylib' (no such file), '/usr/lib/libbuzz.dylib' (no such file)

dist/lib is what I used to setOutputDir of the lib. Is there a way to add/modify paths for dlopen to search in? Something link /usr/local/lib/buzz/... at least?

Here the full build.zig: https://github.com/buzz-language/buzz/blob/main/build.zig

GitHub

👨‍🚀 buzz, A small/lightweight typed scripting language (in development) - buzz/build.zig at main · buzz-language/buzz

dire basin
#

The build package does have a LibExeObjStep.addRPath() method, have you tried that?

#

There's also addLibraryPath() but I assume you might want the former given your output

winged dune
#

Testing out addRPath thx

Also just updated zig, and now I get this: import of file outside package path: '../src/memory.zig' for one of the shared libraries even though i have std_lib.setMainPkgPath(".") which always worked up until now

dire basin
#

Let me peep your code, but first thought is you might need to define a new zig package in build.zig. Then you can do @import("my-package") instead of @import("../../relative/path.zig")

#

What version of zig are you using? I might need to update to reproduce the issue

#

(I'll update to latest nightly)

winged dune
#

0.11.0-dev.426+fc3142aa9

dire basin
#

Hm, I get a compile error related to the recent allocator interface change, in the zig-clap module. What command are you running to build?

winged dune
#

You can go in src/ext/clap and git pull origin master for that they updated their work

dire basin
#

Done:

From https://github.com/Hejsil/zig-clap
 * branch            master     -> FETCH_HEAD
Updating 4f4196f..a1b01ff

But a different error:

./src/obj.zig:299:39: error: container '.cimport:3:18' has no member called 'struct_real_pcre'
    .linux, .freebsd, .openbsd => pcre.struct_real_pcre,
                                      ^
winged dune
#

Yes that’s related to pcre version

dire basin
#

Sorry, you're debugging me debugging you

#

That's not another submodule, yeah? I only see the one in .gitmodules

winged dune
#

What version of pcre do you have? You can try changing the struct name to struct_pcre

#

No pcre is searched in your system

dire basin
#

Ahhhh. Let me check

winged dune
#

Since its almost always there

#

Not sure i’ll keep that dependency though

dire basin
#

8.45-3 on arch core/pcre

winged dune
#

Btw addRPath solves my earlier issue

winged dune
#

Easier than installing older version of pcre

dire basin
#

Bingo, it was real_pcre8_or_16 on my system. Updated and reproduced your import issue

#

So I'm not sure how this worked for you before, I thought this was the case for a while, but: Normally, if you want to import a file, it can't be above the parent of the package's root file.
In your case, the root of the debug package is lib/buzz_debug.zig. It's trying to import from src/memory.zig -- what version were you using prior? Pre-0.10.0?

winged dune
#

No 0.10.0

#

0.10.0-dev.4587+710e2e7f1 actually

dire basin
#

Ok, I might be misremembering. I'll take another look to see if there's a simple answer here

winged dune
#

But my ci builds against zig master so it must be because of a recent zig change

#

exe.setMainPkgPath(".") fixed that issue before

dire basin
#

Oh boy this is a stage1 error

#

I'll look more, that may not be conclusive evidence

west meteor
dire basin
#

I'm wondering if something fucked up happened here https://github.com/ziglang/zig/pull/13652
I installed zig fresh and the path resolution was broken unless I put lib as a sibling to the zig binary, which was not an issue before

west meteor
#

Probably. Without tests I can't tell what are expectations vs conventions.

#

I guess making things abit more stricter for path resolving doesnt sound too aweful though.

dire basin
#

Smells like a nasty bug. I'll try to create a reproduction snippet and open an issue if there isn't one that's directly related