Building fails on MacOS, example fails after fixing build #2
Comments
|
I apologize, this wasn't unexpected since I don't have a mac to test on. I
think you've given me enough information to fix it however. If I do that
would you be able to test it again?
…On Wed, Sep 2, 2020 at 1:43 PM David Ed Mellum ***@***.***> wrote:
The build fails on MacOS after a brew install krb5 as homebrew installs
into /usr/local/opt/krb5. After setting DYLD_FALLBACK_LIBRARY_PATH to
/usr/local/opt/krb5 (which homebrew doesn't automatically recommend) the
build still fails as krb5 builds .dylib files instead of .so. If
libgssapi_krb5.dylab is renamed to libgssapi_krb5.so the build completes.
However running the krb5 example segfaults with a EXC_BAD_ACCESS. Running
through lldb it looks like the segfaults comes from
libgssapi::oid::OidSet::add.
I don't have much experience binding to C libraries from Rust. Am I doing
something crazy here or is something weird happening with the MacOS
bindings? 😄
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWJHLG4KKKCOBCATPOQZX3SDZ73RANCNFSM4QTNKSNA>
.
|
|
I can absolutely test it again! 😄 |
|
I just committed a fix, and tested that it still builds on linux. Would it
be possible for you to check it out from git and see if you can cargo build
the libgssapi-sys crate? If that works then I'll release a new version.
…On Wed, Sep 2, 2020 at 2:36 PM David Ed Mellum ***@***.***> wrote:
I can absolutely test it again! 😄
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWJHLGKUBGZAKECWJSPG3LSD2GB7ANCNFSM4QTNKSNA>
.
|
|
With the update it now finds the shared library, but I had to add a clang_arg to get the include path right: |
|
With the patched libgssapi-sys, I tried to do a |
|
hmm, thats unfortunate. Which kerberos distribution are you building? IIRC
both MIT and Heimdal support those extensions.
I can make those functions optional features, but ideally I'd like to understand why they're missing, because the standard wrap/unwrap functions are much slower.
…On Fri, Sep 4, 2020 at 8:59 PM David Harks ***@***.***> wrote:
With the patched libgssapi-sys, I tried to do a cargo test, but it seems
to be missing some symbols:
= note: Undefined symbols for architecture x86_64:
"_gss_wrap_iov_length", referenced from:
libgssapi::context::wrap_iov_length::hc87f1ab1b3d40235 in liblibgssapi-f998edf59828b990.rlib(libgssapi-f998edf59828b990.zltozf8lipibdfn.rcgu.o)
"_gss_unwrap_iov", referenced from:
libgssapi::context::unwrap_iov::h2b3f0dd899ab7ad9 in liblibgssapi-f998edf59828b990.rlib(libgssapi-f998edf59828b990.zltozf8lipibdfn.rcgu.o)
"_gss_wrap_iov", referenced from:
libgssapi::context::wrap_iov::he487c776420a8018 in liblibgssapi-f998edf59828b990.rlib(libgssapi-f998edf59828b990.zltozf8lipibdfn.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWJHLFS4C4MQFH5HYKWXV3SEGEOBANCNFSM4QTNKSNA>
.
|
I'm just naively installing krb5 from homebrew, which is a packaged build of MIT Kerberos. I'm going to try to build it from source myself to see if we can make the build expose those symbols. That said, I also just learned that Apple includes a Heimdal distribution in OSX. I'll experiment with that too. |
|
Building MIT Kerberos from source helped me run the tests. There's not that many flags in the Homebrew formula, so I'm a little unsure what's causing the problems. I'll try compiling with each of the flags till I get the problem again. |
|
I have a friend with a mac, I'm going to try to get access to it ...
…On Sat, Sep 5, 2020 at 10:03 AM David Harks ***@***.***> wrote:
hmm, thats unfortunate. Which kerberos distribution are you building? IIRC
both MIT and Heimdal support those extensions. I can make those functions
optional features, but ideally I'd like to understand why they're missing,
because the standard wrap/unwrap functions are much slower.
I'm just naively installing krb5 from homebrew, which is a packaged build
of MIT Kerberos. I'm going to try to build it from source myself to see if
we can make the build expose those symbols.
That said, I also just learned that Apple includes a Heimdal distribution
in OSX. I'll experiment with that too.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWJHLECCGVWRD2JCDJQW23SEJALHANCNFSM4QTNKSNA>
.
|
|
gss_iov_* functions are technically extensions to the gssapi standard, but
they have been supported for a very long time by pretty much everything, I
guess homebrew somehow convinced MIT's configure script to disable them ...
…On Sat, Sep 5, 2020 at 10:31 AM David Ed Mellum ***@***.***> wrote:
Building MIT Kerberos from source helped me run the tests. There's not
that many flags in the Homebrew formula
<https://github.com/Homebrew/linuxbrew-core/blob/master/Formula/krb5.rb>,
so I'm a little unsure what's causing the problems. I'll try compiling with
each of the flags till I get the problem again.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWJHLCPDCAXTFISXLVPDPLSEJDT5ANCNFSM4QTNKSNA>
.
|
|
I'm probably doing something weird, but I'm not able to reproduce the missing symbols by building from source while trying to do the same thing the Homebrew formula does. |
|
@edmellum interesting -- do you have anything special set in your environment? I haven't been able to avoid the missing symbols, even when building from source. I even made sure that the build was picking up the Homebrew OpenSSL, and yet it still complains. Doing ...so the symbols are there. Why can't the linker find them? |
|
Aha! This lets me run |
|
...now I get the segfault (this is what you saw too, right @edmellum ?) |
|
Yeah that’s one of the segfaults I’ve gotten. Seems like we’re synced up! 😄 Building with debug symbols should give you line numbers for krb5 too. The other segfaults I’ve gotten might be because of all my experimentation messing stuff up. |
EDIT: I take that back. There's no indication it's linking any of the built-in libs. I did try to compile against the built-in framework, which is supposedly Heimdal, but it's missing several definitions -- it might be pretty old. |
|
Ok, I got access to a mac, but no admin access. The built in Heimdal is super old, and it lacks the gss_iov extensions. The segfault could be a couple of things. make sure it's not linking to both libraries, or the wrong one, IIRC 'otool -L' can tell you that on a mac. It's also possible you're linking to the correct library, but you're reading the tickets created by Apple's ancient Heimdal and that's not working. So if possible, kinit with your MIT kerberos install. I will poke around as much as I can without admin access and try to figure out how to make something work with this mess. |
|
OK, I verified that I'm not multiply linking and that the ticket is generated with the MIT kerberos tools. One other note -- I have |
|
I added a breakpoint at |
|
it looks like the oid set is invalid ... that's strange. I did some more
digging and found that the heimdal Apple has installed is deprecated, they
have built a framework called GSS. Since the goal is to integrate into the
platform, I will look into using that, though I still would like to figure
out this segfault.
…On Sun, Sep 6, 2020 at 10:59 AM David Harks ***@***.***> wrote:
I added a breakpoint at oid.rs:193 and inspected self:
(lldb) print *self
(libgssapi::oid::Oid) $0 = (length = 9, elements = "*\x86H\x86\x02+\x06\x01\x05\x02\x05*\x85p+\r\x1d*\x86H\x86\x02\x05\x0e")
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWJHLBT35PRQF6A35DZUELSEOPTTANCNFSM4QTNKSNA>
.
|
|
Aha, that makes sense. Looks like the IOV stuff is "ApplePrivate" but the rest might be there. |
|
I had a bit of free time so I hid the IOV functions via cfg and linked against the GSS framework: I end up segfaulting at a similar spot: |
|
There's clearly something wrong, I'll try to dig in this week.
On Tuesday, September 8, 2020, David Harks ***@***.***> wrote:
I had a bit of free time so I hid the IOV functions via cfg and linked
against the GSS framework:
❯ otool -L target/debug/examples/krb5
target/debug/examples/krb5:
/System/Library/Frameworks/GSS.framework/Versions/A/GSS (compatibility
version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1281.100.1)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version
1.0.0)
I end up segfaulting at exactly the same spot:
❯ lldb target/debug/examples/krb5
(lldb) target create "target/debug/examples/krb5"
Current executable set to
'/Users/dharks/projects/libgssapi/libgssapi/target/debug/examples/krb5'
(x86_64).
(lldb) run ***@***.***
Process 41211 launched:
'/Users/dharks/projects/libgssapi/libgssapi/target/debug/examples/krb5'
(x86_64)
import name
Process 41211 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff6eaed9a9
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 169
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
-> 0x7fff6eaed9a9 <+169>: movq (%rsi), %rcx
0x7fff6eaed9ac <+172>: movq (%rsi,%rdx), %r8
0x7fff6eaed9b0 <+176>: movq %rcx, (%rdi)
0x7fff6eaed9b3 <+179>: movq %r8, (%rdi,%rdx)
Target 0: (krb5) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x00007fff6eaed9a9
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 169
frame #1: 0x00007fff37493614 GSS`_gss_copy_oid + 148
frame #2: 0x00007fff374929b4 GSS`gss_import_name + 228
frame #3: 0x0000000100018bde
krb5`libgssapi::name::Name::new::hd9a4803f6311fbb7(s=(data_ptr =
"nfs@localhost", length = 13), kind=Option<&libgssapi::oid::Oid> @
0x00007ffeefbfe9f0) at name.rs:77:13
frame #4: 0x0000000100003d18
krb5`krb5::setup_server_ctx::h1ecdfe683b0a2b35(service_name=(data_ptr =
"nfs@localhost", length = 13), desired_mechs=0x00007ffeefbfef28) at
krb5.rs:91:16
frame #5: 0x00000001000049bf
krb5`krb5::run::hd43320aa70b0e1c0(service_name=(data_ptr = "nfs@localhost",
length = 13)) at krb5.rs:121:31
frame #6: 0x0000000100005b02 krb5`krb5::main::hf4e1f8e36fd691db at
krb5.rs:147:15
frame #7: 0x0000000100008e0e
krb5`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h96d13f9372e6ff3e
at rt.rs:67:34
frame #8: 0x0000000100039759
krb5`std::rt::lang_start_internal::hf7eb5bf96c0eb063 [inlined]
std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hc929fc692f6f0cf9
at rt.rs:52:13 [opt]
frame #9: 0x000000010003974e
krb5`std::rt::lang_start_internal::hf7eb5bf96c0eb063 [inlined]
std::panicking::try::do_call::hd19aaf48f3a9c904 at panicking.rs:297 [opt]
frame #10: 0x000000010003974e
krb5`std::rt::lang_start_internal::hf7eb5bf96c0eb063 [inlined]
std::panicking::try::h32c9e7d0f5011b7f at panicking.rs:274 [opt]
frame #11: 0x000000010003974e
krb5`std::rt::lang_start_internal::hf7eb5bf96c0eb063 [inlined]
std::panic::catch_unwind::hfd90c56a25f83b76 at panic.rs:394 [opt]
frame #12: 0x000000010003974e
krb5`std::rt::lang_start_internal::hf7eb5bf96c0eb063 at rt.rs:51 [opt]
frame #13: 0x0000000100008df1
krb5`std::rt::lang_start::h029fbc2009511973(main=(krb5`krb5::main::hf4e1f8e36fd691db
at krb5.rs:142), argc=2, argv=0x00007ffeefbff7e0) at rt.rs:67:5
|
I narrowed it down a bit further -- looks like it's your favorite thing, OIDs. If I substitute the OID definitions listed in the headers for the ones in oid.rs, it works. |
|
Horrible. At least I know where to start.
On Tuesday, September 8, 2020, David Harks ***@***.***> wrote:
There's clearly something wrong, I'll try to dig in this week.
I narrowed it down a bit further -- looks like it's your favorite thing,
OIDs. If I substitute the OID definitions listed in the headers for the
ones in oid.rs, it works.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.<
|
|
Aha! I think I see the issue. On Linux, bindgen generates this for the But on Mac, it generates: So on Mac, the I added the |
|
I put my changes on a branch; feel free to cherry-pick in whatever you like... https://github.com/dwink/libgssapi/tree/macos_gss_framework |
|
Thank's a lot, I'll do that. I want to go through and review the code to
make sure there isn't somewhere else I'm making the same mistake, I hope to
do that this week, then I'll put together another release. I guess,
unfortunately, the gss_iov parts are going to have to be made a feature.
That's really too bad, because they improve performance a lot, but *shrug*
Apple.
…On Tue, Sep 8, 2020 at 5:39 PM David Harks ***@***.***> wrote:
I put my changes on a branch; feel free to cherry-pick in whatever you
like...
https://github.com/dwink/libgssapi/tree/macos_gss_framework
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWJHLGQMOYUQLRML5KJQPDSE2P7VANCNFSM4QTNKSNA>
.
|
|
Yeah, Apple made them private. Maybe their implementation uses them under the hood somehow...? Looks like some folks just link them in anyhow: |
|
I believe this is now resolved, including the iov bits. If possible please test. I can't since I don't have admin access to join the mac I'm using to a kerberos realm. The issue with the oid struct was just stupidity on my part, I should never have copied what bindgen produced, and the worst part is that it wasn't even necessary. I've audited the code and managed to eliminate all uses of transmute, and I don't see any similar errors. |
|
Well, it definitely doesn't segfault, but it also can't seem to find the right credentials: I can auth against this KDC from a Linux host and the example program works perfectly there. Any ideas how to troubleshoot this Heimdal thing? |
|
Do you have a TGT? What's the output of klist? That's the place to start. |
|
Nevermind, it was a DNS issue. (It's always a DNS issue, right?) It works! But the iov stuff fails: |
|
Fun times. I guess it'll be a feature then, because I'm not buying a mac for this :P |
I don't blame you. Besides, even if we did get it working, if someone were to use this crate to ship something to the App Store Apple would reject it for linking those __ApplePrivate symbols anyhow. |
|
New release published. Build with --no-default-features on macos. |
This was referenced Jul 29, 2023
dequbed
added a commit
to dequbed/rsasl
that referenced
this issue
Sep 12, 2023
Resolves #29 I'm not sure if the `oiv` and `localname` are needed for the purposes of this library. If so maybe could add a new flag so that they can be optional included. It seems there's no support for building libgssapi on macs without excluding the default features: estokes/libgssapi#2
dequbed
added a commit
to dequbed/rsasl
that referenced
this issue
Sep 12, 2023
v2.0.1 release Fixed ===== - #29 — `GSSAPI` fails to build on macOS This issue seems to be caused by the same problem as [estokes/libgssapi#2](estokes/libgssapi#2). Building libgssapi without default features solves this build issue. * tag 'v2.0.1': Bump version numbers to v2.0.1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The build fails on MacOS after a
brew install krb5as homebrew installs into/usr/local/opt/krb5. After settingDYLD_FALLBACK_LIBRARY_PATHto/usr/local/opt/krb5(which homebrew doesn't automatically recommend) the build still fails as krb5 builds.dylibfiles instead of.so. Iflibgssapi_krb5.dylabis renamed tolibgssapi_krb5.sothe build completes. However running the krb5 example segfaults with aEXC_BAD_ACCESS. Running through lldb it looks like the segfaults comes fromlibgssapi::oid::OidSet::add.I don't have much experience binding to C libraries from Rust. Am I doing something crazy here or is something weird happening with the MacOS bindings? 😄
The text was updated successfully, but these errors were encountered: