Bug 194609 - [patch] archivers/liblz4 doesn't compile on amd64
Summary: [patch] archivers/liblz4 doesn't compile on amd64
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Adam Weinberger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-26 12:42 UTC by rsmith
Modified: 2014-12-06 19:42 UTC (History)
2 users (show)

See Also:
rsmith: maintainer-feedback? (adamw)


Attachments
Patch for the port makefile. (323 bytes, patch)
2014-10-26 12:42 UTC, rsmith
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rsmith 2014-10-26 12:42:44 UTC
Created attachment 148662 [details]
Patch for the port makefile.

On amd64 the build fails trying to build a 32-bit version of lz4;

# env MAKE_JOBS_UNSAFE=yes make
===>  License BSD2CLAUSE GPLv2 accepted by the user
===>   liblz4-123 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by liblz4-123 for building
===>  Extracting for liblz4-123
=> SHA256 Checksum OK for lz4-123.tar.gz.
===>  Patching for liblz4-123
/usr/bin/sed -i.bak -e 's|kFreeBSD|& FreeBSD|'  /usr/ports/archivers/liblz4/work/Cyan4973-lz4-c0054ca/Makefile /usr/ports/archivers/liblz4/work/Cyan4973-lz4-c0054ca/programs/Makefile
/usr/bin/sed -i.bak -e '/^all:/s|fullbench.*||'  /usr/ports/archivers/liblz4/work/Cyan4973-lz4-c0054ca/programs/Makefile
===>   liblz4-123 depends on executable: gmake - found
===>   liblz4-123 depends on executable: pkgconf - found
===>  Configuring for liblz4-123
===>  Building for liblz4-123
gmake[1]: Entering directory '/usr/ports/archivers/liblz4/work/Cyan4973-lz4-c0054ca'
compiling static library
compiling dynamic library
creating versioned links
gmake[2]: Entering directory '/usr/ports/archivers/liblz4/work/Cyan4973-lz4-c0054ca/programs'
cc      -I..  -O2 -pipe  -fno-strict-aliasing -I. -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes -DLZ4_VERSION=\"r123\"  -DDISABLE_LZ4C_LEGACY_OPTIONS ../lz4.c ../lz4hc.c ../xxhash.c bench.c lz4io.c lz4cli.c -o lz4
cc      -I..  -O2 -pipe  -fno-strict-aliasing -I. -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes -DLZ4_VERSION=\"r123\"  ../lz4.c ../lz4hc.c ../xxhash.c bench.c lz4io.c lz4cli.c -o lz4c
cc -m32 -I..  -O2 -pipe  -fno-strict-aliasing -I. -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes -DLZ4_VERSION=\"r123\"  ../lz4.c ../lz4hc.c ../xxhash.c bench.c lz4io.c lz4cli.c -o lz4c32
/usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:80: recipe for target 'lz4c32' failed
gmake[2]: *** [lz4c32] Error 1
gmake[2]: Leaving directory '/usr/ports/archivers/liblz4/work/Cyan4973-lz4-c0054ca/programs'
Makefile:95: recipe for target 'lz4programs' failed
gmake[1]: *** [lz4programs] Error 2
gmake[1]: Leaving directory '/usr/ports/archivers/liblz4/work/Cyan4973-lz4-c0054ca'
*** Error code 1

My proposed fix is to use the `default` target instead of the `all` target.
This builds and installs correctly.

-----
diff -ruN liblz4.orig/Makefile liblz4/Makefile
--- liblz4.orig/Makefile        2014-10-26 09:50:34.000000000 +0100
+++ liblz4/Makefile     2014-10-26 13:33:49.000000000 +0100
@@ -23,7 +23,7 @@
 USES=          gmake pkgconfig
 USE_LDCONFIG=  yes
 
-ALL_TARGET=    all liblz4 liblz4.pc
+ALL_TARGET=    default liblz4.pc
 SO_VER=                1.3.1
 
 post-patch:
-----
Comment 1 Bugzilla Automation freebsd_committer freebsd_triage 2014-10-26 12:42:44 UTC
Auto-assigned to maintainer adamw@FreeBSD.org
Comment 2 Adam Weinberger freebsd_committer freebsd_triage 2014-10-26 15:18:54 UTC
I cannot reproduce this in poudriere jails in 8/amd64, 9/amd64, 10/amd64, or head/amd64.

Can you give some more information about your build environment?
Comment 3 rsmith 2014-10-27 23:36:28 UTC
OS data:
FreeBSD 10.1-PRERELEASE #0 r273434: Wed Oct 22 02:04:43 CEST 2014 
/usr/obj/usr/src/sys/GENERIC  amd64

My build environment isn't anything special AFAIK. I'm not using a jail.

My make.conf (leaving out port-specific parts) is below;
----- make.conf -----
# Documentation languages
DOC_LANG=en_US.ISO8859-1

# Flags for all ports
WITH_GALLIUM=yes
WITH_PKG=yes

DEFAULT_VERSIONS= ruby=2.1 python3=3.4
----- make.conf -----

I am puzzled as to why cc [FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512] (or rather ld) is looking for a libgcc.a?
Maybe because we're still using an old GNU ld?

My libmap*.conf are the default examples.

Anything else you want to know?
Comment 4 Adam Weinberger freebsd_committer freebsd_triage 2014-11-13 21:42:46 UTC
Sorry, but I stil can't replicate this build failure. It's building successfully on my jails, and on the package build clusters, on all archs and FreeBSD versions.

I'm going to close this PR as "Unable to reproduce," but if you can show me how to replicate the failure please by all means re-open it.
Comment 5 Matthias Fechner freebsd_committer freebsd_triage 2014-11-15 09:25:56 UTC
Thanks, had same problem, patch fixed it.
Comment 6 geoffroy desvernay 2014-12-03 16:26:02 UTC
same problem here (hit on different 10.1 machines - make and poudriere builds), fixed by this patch. thank you !
Comment 7 Adam Weinberger freebsd_committer freebsd_triage 2014-12-04 13:35:59 UTC
Okay. I still can't reproduce this myself but it's clearly affecting people. I will aim to commit this later today.
Comment 8 commit-hook freebsd_committer freebsd_triage 2014-12-06 19:40:40 UTC
A commit references this bug:

Author: adamw
Date: Sat Dec  6 19:40:19 UTC 2014
New revision: 374141
URL: https://svnweb.freebsd.org/changeset/ports/374141

Log:
  I was never able to replicate this, but a number of people have reported that
  liblz4 fails to build on amd64, and they all agree that this patch fixes it.

  PR:		194609
  Submitted by:	Roland Smith

Changes:
  head/archivers/liblz4/Makefile
Comment 9 Adam Weinberger freebsd_committer freebsd_triage 2014-12-06 19:42:21 UTC
Sorry it's taken so long to commit this. I've been trying to replicate it but I just haven't been able to.

Thanks for identifying the problem and doing all the legwork on fixing it!