Smalltalk › Squeak › Squeak VM

libtool unrecognized option `--preserve-dup-deps'

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Ben Coman

libtool unrecognized option `--preserve-dup-deps'

I hit a snag building pharo debug VM...

$ cd build.linux32x86/pharo.cog.spur/build.debug.
$ ./mvm
"libtool: unrecognized option `--preserve-dup-deps'"

I see...
$ ./libtool --version
ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)

but preserve-dup-deps was added a couple of months later 2001-11-27
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=5b4575cf0aee7853c6a91aa844fc2b3168476483

and libtool latest stable version is 2.5.6 (2015/02/15)

By doing... $ sudo chattr +i libtool

I found libtool was created by configure...
rm: cannot remove 'libtool': Operation not permitted
chmod: changing permissions of 'libtool': Operation not permitted

$ ./mvm invokes...
../../../platforms/unix/config/configure

in which folder is ltmain.sh having...
PROGRAM=ltmain.sh
PACKAGE=libtool
VERSION=1.4.2
TIMESTAMP=" (1.922.2.53 2001/09/11 03:18:52)"

What is involved in updating libtool?

btw, this is on 32-bit Debian 8 Jessie, and...
$ git log
==> Author: Eliot Miranda <[hidden email]>
Date: Sat Feb 18 07:43:47 2017 -0800
CogVM source as per VMMaker.oscog-eem.2134
Move the SpurPlanningCompactor to tip. It is now ready for prime time.

cheers -ben

Holger Freyther

Re: libtool unrecognized option `--preserve-dup-deps'

> On 19 Feb 2017, at 17:09, Ben Coman <[hidden email]> wrote:
>
>
> I hit a snag building pharo debug VM...

>
> By doing... $ sudo chattr +i libtool
>
> I found libtool was created by configure...
> rm: cannot remove 'libtool': Operation not permitted
> chmod: changing permissions of 'libtool': Operation not permitted
>
> $ ./mvm invokes...
> ../../../platforms/unix/config/configure

pushd ../../../platforms/unix/config
make configure

sorry about that. Normally one would not check-in a configure script (and related files such as libtool) and I thought I could avoid having to delete these files and just re-generate it when needed/wanted. I had to add the --preserve-dup-deps option to be able to link with newer libtool and didn't consider that the old copy of libtool would bail out with an error.

Eliot Miranda-2

Re: libtool unrecognized option `--preserve-dup-deps'

Hi Holger, Hi Linux/unix build people

On Sun, Feb 19, 2017 at 3:22 AM, Holger Freyther <[hidden email]> wrote:

> On 19 Feb 2017, at 17:09, Ben Coman <[hidden email]> wrote:
>
>
> I hit a snag building pharo debug VM...

>
> By doing... $ sudo chattr +i libtool
>
> I found libtool was created by configure...
> rm: cannot remove 'libtool': Operation not permitted
> chmod: changing permissions of 'libtool': Operation not permitted
>
> $ ./mvm invokes...
> ../../../platforms/unix/config/configure

pushd ../../../platforms/unix/config
make configure

sorry about that. Normally one would not check-in a configure script (and related files such as libtool) and I thought I could avoid having to delete these files and just re-generate it when needed/wanted. I had to add the --preserve-dup-deps option to be able to link with newer libtool and didn't consider that the old copy of libtool would bail out with an error.

Then let's rewrite the system so that configure is always made, precisely once. We can arrange that there's a real configure (e.g. ../../../platforms/unix/configure/configure) which is invoked from ../../../platforms/unix/config/configure. And we can add a check to ../../../platforms/unix/config/configure that will make ../../../platforms/unix/configure/configure if necessary.

Please, who will volunteer to do this?

_,,,^..^,,,_

best, Eliot

Nicolas Cellier

Re: libtool unrecognized option `--preserve-dup-deps'

Hi Eliot,

I know near to nothing to this configure stuff, so don't consider this answer as volunteering ;).

I just want to report problems:

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.

2017-02-26 2:46 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Holger, Hi Linux/unix build people

On Sun, Feb 19, 2017 at 3:22 AM, Holger Freyther <[hidden email]> wrote:

> On 19 Feb 2017, at 17:09, Ben Coman <[hidden email]> wrote:
>
>
> I hit a snag building pharo debug VM...

>
> By doing... $ sudo chattr +i libtool
>
> I found libtool was created by configure...
> rm: cannot remove 'libtool': Operation not permitted
> chmod: changing permissions of 'libtool': Operation not permitted
>
> $ ./mvm invokes...
> ../../../platforms/unix/config/configure

pushd ../../../platforms/unix/config
make configure

sorry about that. Normally one would not check-in a configure script (and related files such as libtool) and I thought I could avoid having to delete these files and just re-generate it when needed/wanted. I had to add the --preserve-dup-deps option to be able to link with newer libtool and didn't consider that the old copy of libtool would bail out with an error.

Then let's rewrite the system so that configure is always made, precisely once. We can arrange that there's a real configure (e.g. ../../../platforms/unix/configure/configure) which is invoked from ../../../platforms/unix/config/configure. And we can add a check to ../../../platforms/unix/config/configure that will make ../../../platforms/unix/configure/configure if necessary.

Please, who will volunteer to do this?

--
_,,,^..^,,,_
best, Eliot

Holger Freyther

Re: libtool unrecognized option `--preserve-dup-deps'

> On 26 Feb 2017, at 16:33, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Eliot,
> I know near to nothing to this configure stuff, so don't consider this answer as volunteering ;).
> I just want to report problems:
>
> 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.

https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/123 seems to be the easiest fix.

Holger Freyther

Re: libtool unrecognized option `--preserve-dup-deps'

In reply to this post by Nicolas Cellier

> On 26 Feb 2017, at 16:33, Nicolas Cellier <[hidden email]> 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

Nicolas Cellier

Re: libtool unrecognized option `--preserve-dup-deps'

2017-02-26 10:47 GMT+01:00 Holger Freyther <[hidden email]>:

> On 26 Feb 2017, at 16:33, Nicolas Cellier <[hidden email]> 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?