[prev in list] [next in list] [prev in thread] [next in thread] 

List:       krbdev
Subject:    Re: krb 1.21.2 build fails on macOS 14.2.1
From:       Norm Green <norm.green () gemtalksystems ! com>
Date:       2024-01-09 0:21:45
Message-ID: 62557c1f-dcdc-4097-b359-2eb6c38a5eef () gemtalksystems ! com
[Download RAW message or body]

Specifying -U "_cc_initialize" moves the problem to run-time and the 
client executable fails to load with an unresolved symbol error.

The original workaround, -framework Kerberos, produces a functional 
final library when added to our relink code. I will stick with that for 
now given that we only use the Kerberos client and our overall Kerberos 
usage is limited to a small number of API calls.

Also I wasn't aware that library constructors could be a problem in pure 
C code (the build log shows only gcc is invoked, not g++).
Perhaps there's a way but I've only used them in C++ code.

Thanks again for your rapid response, I appreciate it.

Norm

On 1/8/2024 11:19 AM, Ken Hornstein wrote:
>> Thanks Ken. Adding "-framework Kerberos" to the linker line resolves the
>> issue.
>>
>> I am indeed building the static libs because I use them to create the
>> shared library later.
> I would caution you that this is not guaranteed to work; one thing
> that leaps out to me is that the shared library build uses -DSHARED
> when building library objects which seems to affect the way library
> constructors are built/used; it MAY work now, but there's no assurance
> it will continue to do so in the future.
>
> If your goal is to just to get everything to build and when you construct
> the shared library later you'll add a dependency to the Kerberos framework
> you could consider a linker option like -U cc_initialize (there might
> be more functions you'll need than that one, though).
>
> --Ken

_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
[prev in list] [next in list] [prev in thread] [next in thread]