Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zfs fails to build on x32 ABI #844

Closed
devsk opened this issue Jul 20, 2012 · 7 comments
Closed

zfs fails to build on x32 ABI #844

devsk opened this issue Jul 20, 2012 · 7 comments
Labels
Status: Inactive Not being actively updated Type: Architecture Indicates an issue is specific to a single processor architecture Type: Building Indicates an issue related to building binaries Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@devsk
Copy link

devsk commented Jul 20, 2012

Just filing it here for record keeping.

x32 is a supported new ABI in 3.4.x kernels. The long and pointers are 32-bit. All 64-bit registers are available. Reduced memory footprint in user space and efficient CPU cache line usage makes it more performant.

As far as I understand it, the kernel module for ZFS must compile & link in 64-bit ABI and user space for ZFS can be in any ABI but finding compatible versions of dependent libs like zlib may force to use x32 ABI on a x32 system.

First failure in the zfs build inside a x32 chroot from gentoo stage3:

/bin/sh ../../libtool --tag=CC --silent --mode=compile gcc -DHAVE_CONFIG_H -include ../../zfs_config.h -I../../lib/libspl/include -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-unused-but-set-variable -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DTEXT_DOMAIN="zfs-linux-user" -Wframe-larger-than=1024 -O2 -march=native -fforce-addr -fomit-frame-pointer -pipe -ftracer -MT xdr.lo -MD -MP -MF .deps/xdr.Tpo -c -o xdr.lo test -f '../../lib/libspl/xdr.c' || echo './'../../lib/libspl/xdr.c
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/include/sys/time.h:31,
from ../../lib/libspl/gethrestime.c:28:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/mkdirp.c:39:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/include/sys/list_impl.h:30,
from ../../lib/libspl/include/sys/list.h:29,
from ../../lib/libspl/list.c:30:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
make[4]: *** [gethrestime.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/strlcat.c:28:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/include/unistd.h:43,
from ../../lib/libspl/getexecname.c:29:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/include/statcommon.h:32,
from ../../lib/libspl/timestamp.c:29:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from /usr/include/rpc/xdr.h:38,
from ../../lib/libspl/include/rpc/xdr.h:35,
from ../../lib/libspl/xdr.c:32:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/include/zone.h:31,
from ../../lib/libspl/zone.c:26:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
make[4]: *** [getexecname.lo] Error 1
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/include/sys/mnttab.h:35,
from ../../lib/libspl/getmntany.c:34:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
In file included from ../../lib/libspl/include/sys/types.h:30:0,
from ../../lib/libspl/include/sys/time.h:31,
from ../../lib/libspl/gethrtime.c:28:
../../lib/libspl/include/sys/isa_defs.h:129:2: error: #error "Both _ILP32 and _LP64 are defined"
../../lib/libspl/timestamp.c: In function 'print_timestamp':
../../lib/libspl/timestamp.c:46:3: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'time_t' [-Wformat]
make[4]: *** [timestamp.lo] Error 1

@ryao
Copy link
Contributor

ryao commented Jul 21, 2012

Jory Pratt, another Gentoo developer, informed me that emerge sys-fs/zfs built successfully on x32 a few hours ago. Which kernel sources did you use and had you built your kernel before attempting to build this?

@devsk
Copy link
Author

devsk commented Jul 21, 2012

I am emerge'ing sys-fs/zfs-0.6.0_rc9-r5::gentoo from the tree and I see the above messages. SPL installed fine. Is he running a later version of the ebuild?

I am building against 3.4.4, which is fully built and has SPL modules in /lib/modules.

@FransUrbo
Copy link
Contributor

@devsk @ryao @behlendorf Considering this is almost two years old, against an ancient version of both zfs and kernel, can we close this? Or is this still an issue, there's been substantial support added for x32 since it was first issued?

@behlendorf
Copy link
Contributor

Clearly nobody feels to strongly about this. Yes, let's close it out until we have a more actionable bug.

@behlendorf behlendorf removed this from the 0.7.0 milestone Oct 6, 2014
@fling-
Copy link
Contributor

fling- commented Nov 12, 2016

build fails with "Both _ILP32 and _LP64 are defined" error in lib/libspl/include/sys/isa_defs.h
build.log

@behlendorf
Copy link
Contributor

Reopening since this is clearly still an issue. Perhaps someone will find the time to investigate these build failures.

@behlendorf behlendorf reopened this Nov 13, 2016
@nabijaczleweli
Copy link
Contributor

hi
DSC_0773

@nabijaczleweli nabijaczleweli mentioned this issue May 22, 2020
11 tasks
behlendorf pushed a commit that referenced this issue May 28, 2020
Given the following test program:
  #include <time.h>
  #include <stdio.h>
  #include <stdint.h>
  int main() {
    printf("time_t:    %d\n", sizeof(time_t));
    printf("long:      %d\n", sizeof(long));
    printf("long long: %d\n", sizeof(long long));
  }

These are output on various x86 architectures:
  x32$   time_t:    8
  x32$   long:      4
  x32$   long long: 8

  amd64$ time_t:    8
  amd64$ long:      8
  amd64$ long long: 8

  i386$  time_t:    4
  i386$  long:      4
  i386$  long long: 8

Therefore code using "%l[du]" to format time_ts produced warnings on x32

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@gmail.com>
Closes #10357
Closes #844
as-com pushed a commit to as-com/zfs that referenced this issue Jun 20, 2020
Given the following test program:
  #include <time.h>
  #include <stdio.h>
  #include <stdint.h>
  int main() {
    printf("time_t:    %d\n", sizeof(time_t));
    printf("long:      %d\n", sizeof(long));
    printf("long long: %d\n", sizeof(long long));
  }

These are output on various x86 architectures:
  x32$   time_t:    8
  x32$   long:      4
  x32$   long long: 8

  amd64$ time_t:    8
  amd64$ long:      8
  amd64$ long long: 8

  i386$  time_t:    4
  i386$  long:      4
  i386$  long long: 8

Therefore code using "%l[du]" to format time_ts produced warnings on x32

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@gmail.com>
Closes openzfs#10357
Closes openzfs#844
(cherry picked from commit a1ba120)
jsai20 pushed a commit to jsai20/zfs that referenced this issue Mar 30, 2021
__x86_64__ && _ILP32 => don't forcibly define _LP64

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@gmail.com>
Closes openzfs#10357
Closes openzfs#844
jsai20 pushed a commit to jsai20/zfs that referenced this issue Mar 30, 2021
Given the following test program:
  #include <time.h>
  #include <stdio.h>
  #include <stdint.h>
  int main() {
    printf("time_t:    %d\n", sizeof(time_t));
    printf("long:      %d\n", sizeof(long));
    printf("long long: %d\n", sizeof(long long));
  }

These are output on various x86 architectures:
  x32$   time_t:    8
  x32$   long:      4
  x32$   long long: 8

  amd64$ time_t:    8
  amd64$ long:      8
  amd64$ long long: 8

  i386$  time_t:    4
  i386$  long:      4
  i386$  long long: 8

Therefore code using "%l[du]" to format time_ts produced warnings on x32

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@gmail.com>
Closes openzfs#10357
Closes openzfs#844
pcd1193182 pushed a commit to pcd1193182/zfs that referenced this issue Sep 26, 2023
Bumps [flate2](https://github.com/rust-lang/flate2-rs) from 1.0.25 to 1.0.26.
- [Release notes](https://github.com/rust-lang/flate2-rs/releases)
- [Commits](rust-lang/flate2-rs@1.0.25...1.0.26)

---
updated-dependencies:
- dependency-name: flate2
  dependency-type: indirect
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Inactive Not being actively updated Type: Architecture Indicates an issue is specific to a single processor architecture Type: Building Indicates an issue related to building binaries Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Development

No branches or pull requests

7 participants
@behlendorf @FransUrbo @devsk @ryao @nabijaczleweli @fling- and others