Closed GoogleCodeExporter closed 8 years ago
ok, I guess the problem is that the link should be relative, instead of
absolute.
Will correct that.
Sidenote : it would be better if I could perform the same installation test as
yours, it would allow to detect all these conditions before publication
Original comment by yann.col...@gmail.com
on 23 Mar 2014 at 12:00
Original comment by yann.col...@gmail.com
on 23 Mar 2014 at 12:00
You can have an archlinux chroot, use this PKGBUILD[1], and the devtools to
build the package. All freely available.
[1]
https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/lz4
Original comment by sebastien.luttringer
on 23 Mar 2014 at 12:15
Please find in attached file a hotfix for issue 124 & 125.
It regenerate CFLAGS correction, which somehow disappeared from r115,
and makes lz4cat link relative, to make it work using above installation script.
Original comment by yann.col...@gmail.com
on 23 Mar 2014 at 12:15
Here is another rc116, which should not change anything on Linux (it just
conforms to a different naming convention of dynamic libraries for OSX).
I'm relying on your test to know if it works properly or not.
I realize that having the package working fine on my test system is not enough.
Original comment by yann.col...@gmail.com
on 23 Mar 2014 at 1:52
Now it's make install which fail.
==> Starting build()...
compiling static library
compiling dynamic library
creating versioned links
make[1]: Entering directory '/build/lz4/src/lz4/programs'
cc -I.. -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -I. -std=c99 -O3 -Wall -W -Wundef
-DLZ4_VERSION=\"r116\" -DDISABLE_LZ4C_LEGACY_OPTIONS ../lz4.c ../lz4hc.c
bench.c xxhash.c lz4io.c lz4cli.c -o lz4
cc -I.. -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -I. -std=c99 -O3 -Wall -W -Wundef
-DLZ4_VERSION=\"r116\" ../lz4.c ../lz4hc.c bench.c xxhash.c lz4io.c lz4cli.c -o
lz4c
make[1]: Leaving directory '/build/lz4/src/lz4/programs'
==> Starting check()...
Compressed 323 bytes into 251 bytes ==> 77.71%
Successfully decoded 323 bytes
==> Entering fakeroot environment...
==> Starting package()...
compiling static library
compiling dynamic library
creating versioned links
ln: failed to create symbolic link 'liblz4.so.1': File exists
Makefile:92: recipe for target 'liblz4' failed
make: *** [liblz4] Error 1
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/seblu/build
Original comment by sebastien.luttringer
on 24 Mar 2014 at 12:19
build() {
cd $pkgname
make
}
package() {
cd $pkgname
make install DESTDIR="$pkgdir"
}
Original comment by sebastien.luttringer
on 24 Mar 2014 at 12:20
Indeed.
The issue can happen if compilation was performed before, typically :
make
and then
make install
will try to duplicate the link, which is not useful since the link is already
there.
The temporary solution is to :
make clean
before
make install
But I guess something more foolproof would be preferable.
Original comment by yann.col...@gmail.com
on 24 Mar 2014 at 1:15
The following rc attempts to correct the duplicate link creation issue
by issuing the -f (force) command.
make
followed by
make install
seems to work fine on my Linux test system now.
Regards
Original comment by yann.col...@gmail.com
on 24 Mar 2014 at 1:27
Attachments:
Yes. We typically call make, after we call a check function and we install. If
you clean and rebuild, the two compilation may differ. Although there is few
file to compile, this will double the compilation time.
You can use add the switch -f to ln to avoid this error.
As you didn't release yet, it could be a good idea to fix this before releasing
116.
Original comment by sebastien.luttringer
on 24 Mar 2014 at 1:28
Hi Sebastien
Did the last rc passed your test suite ?
I would like to publish r116 quickly, but it would be a pity if yet another
issue slipped through.
As a sidenote :
I tried to build an ArchLinux configuration which would be able to recreate
your tests conditions, but miserably failed.
I guess the simplest way for me would be to run the test within a ready-to-use
VM. Does such a download exist ?
Regards
Original comment by yann.col...@gmail.com
on 24 Mar 2014 at 4:43
The latest RC did not pass the test. There is failure in make install. Did you
release a new tarball with "ln -s"?
Original comment by sebastien.luttringer
on 24 Mar 2014 at 7:54
well, yes, it's just above in the thread
Original comment by yann.col...@gmail.com
on 24 Mar 2014 at 8:28
Oh, yes, I missed it :) Everything seems ok.
$ tar tvf ./lz4-116-1-x86_64.pkg.tar.xz
-rw-r--r-- root/root 581 2014-03-24 21:53 .PKGINFO
-rw-r--r-- root/root 791 2014-03-24 21:53 .MTREE
drwxr-xr-x root/root 0 2014-03-24 21:53 usr/
drwxr-xr-x root/root 0 2014-03-24 21:53 usr/lib/
drwxr-xr-x root/root 0 2014-03-24 21:53 usr/include/
drwxr-xr-x root/root 0 2014-03-24 21:53 usr/bin/
drwxr-xr-x root/root 0 2014-03-24 21:53 usr/share/
drwxr-xr-x root/root 0 2014-03-24 21:53 usr/share/man/
drwxr-xr-x root/root 0 2014-03-24 21:53 usr/share/man/man1/
-rw-r--r-- root/root 878 2014-03-24 21:53 usr/share/man/man1/lz4.1.gz
lrwxrwxrwx root/root 0 2014-03-24 21:53 usr/bin/lz4cat -> lz4
-rwxr-xr-x root/root 60816 2014-03-24 21:53 usr/bin/lz4
-rwxr-xr-x root/root 61760 2014-03-24 21:53 usr/bin/lz4c
-rwxr-xr-x root/root 12316 2014-03-24 21:53 usr/include/lz4.h
-rwxr-xr-x root/root 8763 2014-03-24 21:53 usr/include/lz4hc.h
lrwxrwxrwx root/root 0 2014-03-24 21:53 usr/lib/liblz4.so.1 ->
liblz4.so.1.0.0
lrwxrwxrwx root/root 0 2014-03-24 21:53 usr/lib/liblz4.so ->
liblz4.so.1.0.0
-rwxr-xr-x root/root 32056 2014-03-24 21:53 usr/lib/liblz4.so.1.0.0
Original comment by sebastien.luttringer
on 24 Mar 2014 at 8:54
great thanks !
I'm going to publish it
Original comment by yann.col...@gmail.com
on 24 Mar 2014 at 8:59
Fixed into r116
Original comment by yann.col...@gmail.com
on 24 Mar 2014 at 9:01
Original issue reported on code.google.com by
sebastien.luttringer
on 23 Mar 2014 at 11:54