[Vm-dev] libtool unrecognized option `--preserve-dup-deps'

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Feb 26 17:48:02 UTC 2017


2017-02-26 10:47 GMT+01:00 Holger Freyther <holger at freyther.de>:

>
>
> > On 26 Feb 2017, at 16:33, Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com> wrote:
> >
> >
>
>
> > Last time I tried to build spur vm on ubuntu 14, the vm compilation did
> not succeed (don't remember how but I can replay it).
> > I got to install an old version of autotools before being able to make
> configure from platforms/unix/config
> > That did not solve anything because now the vm compilation barks about
> mmap being required.
>
> For mmap you want something like this[1]. I have not fully read the macro
> but I think the AC_FUNC_MMAP runs into the mmap_min_addr restriction[2].
> But as most people use a binary version of the VM there is little point to
> check that the system that built the software had a working version (and
> since the late 90s mmap generally works).
>
> holger
>
> [1] https://github.com/pharo-project/pharo-vm/commit/
> 43461db5c154d8c47f3c504a67e55b9890839c74
> [2] https://wiki.debian.org/mmap_min_addr



So the error was as the thread tells:
libtool: unrecognized option `--preserve-dup-deps'

If I want to reconfigure, I note a few warnings
cd platforms/unix/config; make configure
...snip...
autoreconf --install --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros
in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'

then I've got the mmap problem:

cd ../../../build.linux64x64/squeak.cog.spur/build; ./mvm
...snip...
platforms/unix/vm/sqUnixSpurMemory.c:72:3: error: #error "Spur requires
mmap"
 # error "Spur requires mmap"
   ^
make[1]: *** [sqUnixSpurMemory.o] Erreur 1
make: *** [vm/vm.a] Erreur 2

If I apply the patch you're proposing, then mmap passes, and the build
fails a little further:
...snip...
ln -s ../vm-display-X11/.libs/vm-display-X11 libvm-display-X11.so
/bin/bash
/media/psf/Home/Smalltalk/OpenSmalltalk/opensmalltalk-vm/build.linux64x64/squeak.cog.spur/build/libtool
--mode=link gcc -m64 -g -O2 -DNDEBUG -DDEBUGVM=0 -msse2 -D_GNU_SOURCE
-DCOGMTVM=0 -DLSB_FIRST=1  -Wl,-z,now -lGL -lXext  -lSM -lICE   -ldl
-lpthread -lm -lnsl -lpthread -luuid -lX11 -L. -lvm-display-X11
-avoid-version -module -rpath
/media/psf/Home/Smalltalk/OpenSmalltalk/opensmalltalk-vm/products/sqcogspur64linuxht/lib/squeak/`/media/psf/Home/Smalltalk/OpenSmalltalk/opensmalltalk-vm/build.linux64x64/squeak.cog.spur/build/getversion
VERSION_TAG` -o XDisplayControlPlugin.la XDisplayControlPlugin.lo -lutil
-ldl -lpthread -lm -lnsl -lpthread -luuid -lX11
libtool: link: gcc -m64 -shared  -fPIC -DPIC
.libs/XDisplayControlPlugin.o   -lGL -lXext -lSM -lICE -L. -lvm-display-X11
-lutil -ldl -lm -lnsl -lpthread -luuid -lX11  -m64 -O2 -msse2 -Wl,-z
-Wl,now   -Wl,-soname -Wl,XDisplayControlPlugin.so -o
.libs/XDisplayControlPlugin.so
/usr/bin/ld: cannot find -lvm-display-X11
collect2: error: ld returned 1 exit status
make[1]: *** [XDisplayControlPlugin.la] Erreur 1
make: *** [XDisplayControlPlugin.la] Erreur 2


So thanks for the progress.
However it worries me a bit that patches should go to the pharo-vm fork
only.
Why not pushing to opensmalltalk-vm directly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170226/e45d1741/attachment.html>


More information about the Vm-dev mailing list