On Mon, Sep 8, 2014 at 3:53 PM, Sage Weil wrote:
> Ah, I got it to work with AC_COMPILE_IFELSE nad AC_LANG_PROGRAM. Can you
> take a look?
>
> https://github.com/ceph/ceph/pull/2428
Looks fine to me -- except (minor point) I'd probably put arch_x32=0
inside the AC_COMPILE_IFELSE call, e.
On Mon, 8 Sep 2014, Daniel Schepler wrote:
> On Mon, Sep 8, 2014 at 3:28 PM, Sage Weil wrote:
> >> if test x"$cpu" = x"x86_64" || test x"$cpu" = x"i386"; then
> >> cat >conftest.c <<-'EOF'
> >> #if defined(__x86_64__) && defined(__ILP32__)
> >> #error x32
> >> #endif
> >>
On Mon, Sep 8, 2014 at 3:28 PM, Sage Weil wrote:
>> if test x"$cpu" = x"x86_64" || test x"$cpu" = x"i386"; then
>> cat >conftest.c <<-'EOF'
>> #if defined(__x86_64__) && defined(__ILP32__)
>> #error x32
>> #endif
>> EOF
>> $CC -c conftest.c || cpu=x32
>> fi
>
>
On Mon, 8 Sep 2014, Thorsten Glaser wrote:
> Sage Weil dixit:
>
> >I'll apply the original patch (and backport) to start. But making the
> >build properly detect amd64 would be even better. Right now we are
> >testing whether `arch` = 'x86_64'. What should we do to distinguish
> >between an
On Mon, Sep 8, 2014 at 2:52 PM, Thorsten Glaser wrote:
> Daniel Schepler dixit:
>
>>-mx32), and then run file on the test program. If file outputs
>
> No, file(1) is an added dependency, unreliable (can have false
> positives and negatives) and known to change output from time
> to time.
OK...
Daniel Schepler dixit:
>-mx32), and then run file on the test program. If file outputs
No, file(1) is an added dependency, unreliable (can have false
positives and negatives) and known to change output from time
to time.
>Or, less reliably, you could look at the configure triplet, which is
>x86
Sage Weil dixit:
>I'll apply the original patch (and backport) to start. But making the
>build properly detect amd64 would be even better. Right now we are
>testing whether `arch` = 'x86_64'. What should we do to distinguish
>between an x86_64 and x32 build?
Mh okay.
if test x"$cpu" = x"x8
I think the most reliable method would be: compile a test program
using the configured compiler with default flags (i.e. no -m64, -m32,
-mx32), and then run file on the test program. If file outputs
"64-bit.*x86-64" then it's amd64; if file outputs "32-bit.*x86-64"
then it's x32.
Or, less reliabl
On Fri, 5 Sep 2014, Thorsten Glaser wrote:
> Daniel Schepler dixit:
>
> >> Attached patch fixes this by installing yasm on amd64 only.
>
> >Would this really work without also adding Build-Conflicts: yasm [!amd64]?
> >I
>
> Only if we build in clean chroots. Which we do, always.
> B-C is inde
Daniel Schepler dixit:
>> Attached patch fixes this by installing yasm on amd64 only.
>Would this really work without also adding Build-Conflicts: yasm [!amd64]? I
Only if we build in clean chroots. Which we do, always.
B-C is indeed justified here, though.
>think it would probably be a bette
On Wednesday, September 03, 2014 03:14:12 PM Thorsten Glaser wrote:
> yasm is only used on amd64 by the ceph build system, but the
> Debian package installs it on every architecture. x32 is mis‐
> detected as amd64, which is not a problem except we must skip
> the assembly part.
>
> Attached patch
Source: ceph
Version: 0.80.5-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
Hi,
yasm is only used on amd64 by the ceph build system, but the
Debian package installs it on every architecture. x32 is mis‐
detected as amd64, which is no
12 matches
Mail list logo
