Build Error

[Vm900]

Hi,
Been trying to build for centos 7 64bit machine and i keep
getting this error:

/usr/bin/ld: cannot find -lvm-display-X11
collect2: error: ld returned 1 exit status
make[1]: *** [XDisplayControlPlugin.la] Error 1
make: *** [XDisplayControlPlugin.la] Error 2

Can you kindly help
Thanks

[eliotmiranda]

Hi, have you read the build.linux64x64/HowToBuild? Have you installed the X11 development libraries?

…

On Sat, Mar 18, 2017 at 3:53 PM, Vm900 ***@***.***> wrote: Hi, Been trying to build for centos 7 64bit machine and i keep getting this error: /usr/bin/ld: cannot find -lvm-display-X11 collect2: error: ld returned 1 exit status make[1]: *** [XDisplayControlPlugin.la] Error 1 make: *** [XDisplayControlPlugin.la] Error 2 Can you kindly help Thanks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#126>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APHa0FaIHhZmYT6RepUpqo4FZLyavBoOks5rnGBcgaJpZM4MhkcG> .

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

[nicolas-cellier-aka-nice]

Same for me on Ubuntu 14. Here are some extract of the LOG file:

I presume via libtool, the Makefile will generate vm-display-X11/.libs/vm-display-X11 without .so extension:

gcc -m64 -shared  sqUnixX11.lo sqUnixMozilla.lo  -lGL -lXext -lSM -lICE -ldl -lpthread -lm -lnsl -lpthread -luuid -lX11  -Wl,-z -Wl,now -Wl,-soname -Wl,vm-display-X11 -o .libs/vm-display-X11

Then, it will further link against the non existing .so extension

ln -s ../vm-display-X11/.libs/vm-display-X11.so libvm-display-X11.so

And fail to link

/usr/bin/ld: cannot find -lvm-display-X11

[nicolas-cellier-aka-nice]

Googling "libtool missing .so extension" reveals a few old problems relative to some old version of libtool.

For some reason, the libtool copied to build.linux64x64/squeak.cog.spur/build is an old one

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

while the regular ubuntu 14 is

libtool --version
libtool (GNU libtool) 2.4.2

Maybe this is a side effect of installing an old autotools

sudo apt-get install autoconf2.13

Installing an old autotools was required after a recent change, let me remember...
Ah, but it's me who made this recent change to fix some falling builds:

58eb11a

And now, things have changed again... This autoshit is a nightmare.
Let's rewind: the problem was logged in vm-dev archive from february 2017

[Vm-dev] libtool unrecognized option `--preserve-dup-deps'
http://lists.squeakfoundation.org/pipermail/vm-dev/2017-February/024329.html

This was after merging #123

I don't see recent modifications other than rpath...

[eliotmiranda]

Hi Vm900, this is now fixed. See Cog commit 54bab0a

…

On Sat, Mar 18, 2017 at 3:53 PM, Vm900 ***@***.***> wrote: Hi, Been trying to build for centos 7 64bit machine and i keep getting this error: /usr/bin/ld: cannot find -lvm-display-X11 collect2: error: ld returned 1 exit status make[1]: *** [XDisplayControlPlugin.la] Error 1 make: *** [XDisplayControlPlugin.la] Error 2 Can you kindly help Thanks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#126>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APHa0FaIHhZmYT6RepUpqo4FZLyavBoOks5rnGBcgaJpZM4MhkcG> .

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

[Vm900]

Thanks

[nicolas-cellier-aka-nice]

It did not solve the problem for me.
There is no more bad link, but still, the generated library miss a .so extension, so cannot be found via -l option.

I see that we carry an old version of ltmain.sh in platforms/unix/config but we don't have a libtool.m4, all seems included in aclocal.m4, and I think is incompatible with my installed autoconf.

When I install autoconf (2.69) + autoconf2.13 packages, ubuntu is smart enough to auto-detect autoconf version based on some rules... For example:
configure.ac => new autoconf (>= 2.50) while configure.in => old autoconf (>= 2.13)
So not smart enough to use old version and work out of the box...

What works for me (generating the .so extension) is to remember doing this step:

cd platforms/unix/config
make configure

But then,

cd ../../../build.linux64x64/squeak.cog.spur/build
./mvm

still fails for another reason: it does not find the library after Eliot's change...
What is generated is missing the lib prefix

./vm-display-X11/.libs/vm-display-X11.so

What is required is

./vm-display-X11/.libs/libvm-display-X11.so

The old version did work, I'll have to revert, even if a bit more complex

[eliotmiranda]

On Wed, Mar 22, 2017 at 1:38 PM, Nicolas Cellier ***@***.***> wrote: It did not solve the problem for me. There is no more bad link, but still, the generated library miss a .so extension, so cannot be found via -l option. I see that we carry an old version of ltmain.sh in platforms/unix/config but we don't have a libtool.m4, all seems included in aclocal.m4, and I think is incompatible with my installed autoconf. When I install autoconf (2.69) + autoconf2.13 packages, ubuntu is smart enough to auto-detect autoconf version based on some rules... For example: configure.ac => new autoconf (>= 2.50) while configure.in => old autoconf (>= 2.13) So not smart enough to use old version and work out of the box... What works for me (generating the .so extension) is to remember doing this step: cd platforms/unix/config make configure But then, cd ../../../build.linux64x64/squeak.cog.spur/build ./mvm still fails for another reason: it does not find the library after Eliot's change... What is generated is missing the lib prefix ./vm-display-X11/.libs/vm-display-X11.so What is required is ./vm-display-X11/.libs/libvm-display-X11.so The old version did work, I'll have to revert, even if a bit more complex

Please *don't* revert. The old change broke my CentOS 64-bit build. On CentOS, at least in my configuration, there is no .so appended to the shared library so adding the explicit .so breaks my build. My fix avoided that issue.

…

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#126 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APHa0GXmh1DiZ-FhFVvGHroW4jacbjHzks5roYbdgaJpZM4MhkcG> .

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

[nicolas-cellier-aka-nice]

So I've reverted the changes and all is back to normal.
Whenever the build is failing for obscure reason like missing .so extension, please proceed as follow:

• make sure you have the autoconf automake libtool ... niceties installed.
• before building the vm, update with cd platforms/unix/config; make configure

This is also a note for me, because age help me forgetting these nasty details...

These tools are here to make sure that anybody wanting to produce software has lost enough time before ever thinking of it. It's a selective process. One must either be co-opted or go thru a painful initiation.
Also these scripts actively protect the community against any one taking the names too literally and thinking that the build would be automated. How naive this would be...
In the end, I know very well what I want: build a libsomething.so because I'm on linux. But it's better to ask this to a script having dozens of functions, variables and macros substitution because someone else in the world might want something.dll. If possible a script with plenty of incompatible versions hanging around and failing for obscure reasons, something that you can hardly debug step by step and understand...
My own conclusion is that we probably want to attract paranoid people not trusting anything in this parallel world and avoiding too direct path, because who knows, they might get uncovered.

[nicolas-cellier-aka-nice]

Eliot, sorry, I missed your post: we can't let things bugged as they are. The missing .so is a bug, an accident. It's not something that we want to perpetuate. I don't well see how your changes solved it, but they only work in a particular case. So two questions

1. does make configure restore your ability to build?
2. could we then commit the generated configuration to a more reasonable state?

[nicolas-cellier-aka-nice]

Eliot, I published an ugly workaround that first test for missing .so and link whatever it finds... I can build in Ubuntu 14 with and without a make configure.