[20475] in Kerberos_V5_Development
Re: krb 1.21.2 build fails on macOS 14.2.1
daemon@ATHENA.MIT.EDU (Norm Green)
Mon Jan 8 19:22:02 2024
Message-ID: <62557c1f-dcdc-4097-b359-2eb6c38a5eef@gemtalksystems.com>
Date: Mon, 8 Jan 2024 16:21:45 -0800
MIME-Version: 1.0
Content-Language: en-US
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krbdev@mit.edu
From: Norm Green <norm.green@gemtalksystems.com>
In-Reply-To: <202401081919.408JJRm3014987@hedwig.cmf.nrl.navy.mil>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
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
