On Wednesday, 10 January 2018 2:32 AM, Sam Hartman wrote:
> Hugh> This seems to work well for development on the host
> Hugh> architecture and when setting CC="gcc -mXX". It may not work
> Hugh> so well for cross-compiling, where some packages set
> Hugh> CC_FOR_BUILD, BUILD_CC or some other
> "Hugh" == Hugh McMaster writes:
Hugh> Hi Sam, Apologies for the delay in replying. Somehow your
Hugh> message landed in my spam folder.
Hugh> On Friday, 5 January 2018 1:44 PM, Sam Hartman wrote:
>> My plan is to use the following: CC=${CC-cc}
Hi Sam,
Apologies for the delay in replying. Somehow your message landed in my spam
folder.
On Friday, 5 January 2018 1:44 PM, Sam Hartman wrote:
> My plan is to use the following:
> CC=${CC-cc}
> tripple=`$CC -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed
> 's/-pc//' )`
> if [
Hi.
I like the approach of making krb5-config not dynamic, but I'd prefer
to discover the behavior of the compiler rather than to base our
interactions on its filename.
My plan is to use the following:
CC=${CC-cc}
tripple=`$CC -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 's/-pc//'
These are all valid points. But my attempt above was a proof-of-concept of
a different solution focused on pkg-config. It's nowhere near production-ready.
Still, your email got me thinking that we seem to be making this too
complicated. Since the hard-coded libdir path is the problem, wouldn't be
So, I finally got a chance to look at this.
It sounds like you're taking a significantly different approach than we
had discussed earlier.
What we had talked about is parsing the output of $CC. For example
asking gcc what tripple it was built for and going from there.
But what you did is assume
As you can tell I did not get around to looking at this last weekend.
The US holiday ended up taking up more time than I anticipated, and then
I got sick. This week my day job is taking up all my time; hope to have
some Debian cycles next week.
--Sam
On Monday, 20 November 2017 11:07 AM, Sam Hartman wrote:
> Why do you want to replace krb5-config with pkg-config?
> [...]
> Are there advantages/simplicities in coding that led you to that
> approach? I'd like to understand so I can evaluate.
As Ben pointed out, pkgconfig has been replacing the
On Sun, Nov 19, 2017 at 07:07:45PM -0500, Sam Hartman wrote:
>
> Why do you want to replace krb5-config with pkg-config?
> That seems like a good option if we can sell upstream on the idea, but
> something requiring more thought otherwise.
I believe we can consider upstream sold.
pkg-config is
Thanks.
I'll take a look next week.
This looks very promising.
Unless I'm missing something, I think you've done a lot of the work
regardless of whether we want to wrap krb5-config architecture scripts
or wrap a script that calls cross-pkg-config.
Why do you want to replace krb5-config with
On Friday, 17 November 2017 7:26 AM, Sam Hartman wrote:
> Also, if we're moving away from krb5-config, the only strong requirement
> is that krb5-config work correctly on the native architecture.
> We'd like it to work in other cases, but if we're OK telling people who
> are cross-compiling to use
> "Russ" == Russ Allbery writes:
>> But how can we link this output to CC?
Russ> That's a trickier question, since I'm not sure Autoconf or
Russ> make alway exports the current compiler as the CC environment
Russ> variable in all the ways krb5-config is
Hugh McMaster writes:
> What about just calling clang like this?
> clang -dumpmachine | sed 's/pc-//'
That might work, although it would need some verification that this
produces the right result on all of Debian's architectures. (So do mine,
for that matter,
On Thursday, 16 November 2017 10:16 AM, Russ Allbery wrote:
> gcc -print-multiarch will give you what I think is the path component we
> use, although I'm not 100% sure that we always use that value.
> I don't see an equivalent for clang, but:
>clang -print-search-dirs | sed 's/:/\n/g' |
Sam Hartman writes:
> I'd rather find a more clever solution.
> Is there any way to map back from CC to something useful as an
> installation architecture?
> I'd prefer something that worked both for gcc and llvm.
gcc -print-multiarch will give you what I think is the path
Unfortunately, krb5-config is used fairly widely by software not in
Debian.
In the past krb5 has been fairly conservative, which in this case would
mean having krb5-multidev depend on krb5-multidev-bin for a release.
If we did that we would have a solution for buster+1 to make
krb5-multidev m-a
Hi all,
Sorry for the delayed response to this thread. I ran out of time yesterday.
On Mon, 13 Nov 2017 11:58:04 -0500, Sam Hartman wrote:
> so, why don't you take this opportunity to try and sell me on how cool
> multi-arch is for krb5 dev packages and why it provides Debian with neat
> enough
Sam Hartman writes:
> we do ship a pkg-config script and that handles this correctly.
> How does pkg-config figure out which arch you're building for?
pkg-config the command appears to have the same problem. It embeds a
compile-time path of pkgconfig directories to search
control: tags -1 -patch
control: severity -1 wishlist
> "Russ" == Russ Allbery writes:
Russ> Hugh McMaster writes:
>> The packages krb5-multidev and libkrb5-dev are not multi-arch
>> installable.
>> A diff of the i386 and amd64
Benjamin Kaduk writes:
> On Mon, Nov 13, 2017 at 10:51:10AM -0800, Russ Allbery wrote:
>> I'm not sure how best to fix this other than no longer using
>> krb5-config and shipping a pkgconfig script or something. One could
>> move the krb5-config script into an
On Mon, Nov 13, 2017 at 10:51:10AM -0800, Russ Allbery wrote:
>
> I'm not sure how best to fix this other than no longer using krb5-config
> and shipping a pkgconfig script or something. One could move the
> krb5-config script into an architecture-specific directory, but that just
> moves the
Hugh McMaster writes:
> The packages krb5-multidev and libkrb5-dev are not multi-arch installable.
> A diff of the i386 and amd64 variants of krb5-multidev reveals
> a file conflict in /usr/bin/krb5-config(.mit).
> -libdir=${prefix}/lib/i386-linux-gnu/mit-krb5
>
So, I'm uncomfortable making a long-term promise to support krb5-config
in a multi-arch environment.
Today, the multi-arch change is easy to work with.
However, it seems entirely reasonable that the recommended cppflags and
cflags might differ between architectures, and I don't know that I want
Package: krb5-multidev
Version: 1.15.2-2
Severity: important
Tags: patch
Dear Maintainer,
The packages krb5-multidev and libkrb5-dev are not multi-arch installable.
A diff of the i386 and amd64 variants of krb5-multidev reveals
a file conflict in /usr/bin/krb5-config(.mit).
24 matches
Mail list logo