Closed jakebailey closed 8 years ago
Thanks for your bug report. I have the same problem, although for me it seems to be a warning only. I have spent a frustrating hour trying to track it down with no luck. The bug you referenced and corresponding xmlsec change looks promising, but I'm not really sure what to do about it. Thoughts?
Hmm, I guess somehow I missed the word "warning". I should check to see if it actually works and I'm just an idiot. There's another set of bindings for xmlsec, lestrrat/go-xmlsec, which also produces these warnings, so maybe it's not that big of a deal.
The first "solution" that comes to mind is to vendor in that modified xmlsec library, and modify the cgo directives to instead include the modified version, but that working depends on if xmlsec can be statically linked. (I think just xmlsec being static would work, since its dependencies shouldn't care about the modification.)
Are there any other libraries that do something similar to this one? I guess my focus is to get saml working, but having a library that doesn't spit out a bunch of nasty warnings is always nice too.
Yeah, it builds okay, I just didn't know it. Now your saml library gives me expected element type <EntityDescriptor> but have <EntitiesDescriptor>
when it's trying to load the provider data from testshib, but I should probably file that issue over in the other repo.
I (finally!) figured out the correct voodoo in [760a575a8af401915a1a8eb2cbfcd5eb3d429a19] to silence the warnings on darwin/clang and linux/gcc.
I'm trying to use your saml library, but I can't seem to get anything to build because of some issues down in this library. When building, I get:
This seems related to lsh123/xmlsec#10, but you don't use a custom library. How have you been able to build things without hitting this? I've tried this both on my Arch install, and a Docker container with wheezy.