I’m trying to make the UnicodePlugin for an x86 linux. You’d think that would be simple enough but in fact the config fails because it has a hard-coded ARAM path in the UnicodePlugin/acinlude.m4 file - probably my fault from a couple of years ago as it happens.
So, add the x86 path (for the glibconfig.h file; I imagine there is a way to make that get worked out automagically - see the CPPFLAGS line in platforms/unix/plugins/UnicodePlugin/acinclude.m4) and rebuild. Except the mvm script doesn’t re-run the configuration build. OK, delete the dratted config.h to force it to re-run autoconf.
Sigh, nothing doing. No change.
Look in platforms/unix/config and try `make`. Fails at configure.ac line 201. Which is weird because it *must* have worked not so many hours ago when I did a completely scratch load of the source tree on this particular machine.
Suggestions welcomed.
Error output follows -
tim@ubuntu:~/squeak/opensmalltalk-vm/platforms/unix/config$ make configure ./mkacinc > acplugins.m4 + ../vm-display-Quartz/acinclude.m4 + ../vm-display-X11/acinclude.m4 + ../vm-display-custom/acinclude.m4 + ../vm-display-fbdev/acinclude.m4 + ../vm-sound-ALSA/acinclude.m4 + ../vm-sound-MacOSX/acinclude.m4 + ../vm-sound-NAS/acinclude.m4 + ../vm-sound-OSS/acinclude.m4 + ../vm-sound-Sun/acinclude.m4 + ../vm-sound-custom/acinclude.m4 + ../vm-sound-null/acinclude.m4 + ../vm-sound-pulse/acinclude.m4 + ../vm/acinclude.m4 + ../plugins/B3DAcceleratorPlugin/acinclude.m4 + ../plugins/BitBltPlugin/acinclude.m4 + ../plugins/BochsIA32Plugin/acinclude.m4 + ../plugins/BochsX64Plugin/acinclude.m4 + ../plugins/FloatMathPlugin/acinclude.m4 + ../plugins/GdbARMPlugin/acinclude.m4 + ../plugins/IA32ABI/acinclude.m4 + ../plugins/MIDIPlugin/acinclude.m4 + ../plugins/Mpeg3Plugin/acinclude.m4 + ../plugins/PseudoTTYPlugin/acinclude.m4 + ../plugins/UUIDPlugin/acinclude.m4 + ../plugins/UnicodePlugin/acinclude.m4 + ../plugins/UnixOSProcessPlugin/acinclude.m4 + ../plugins/XDisplayControlPlugin/acinclude.m4 aclocal autoconf configure.ac:201: error: possibly undefined macro: AC_PROG_NM If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:219: error: possibly undefined macro: AC_DISABLE_STATIC configure.ac:220: error: possibly undefined macro: AC_PROG_LIBTOOL make: *** [configure] Error 1
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Original Sin is hard to find, but the digitally enhanced version is readily available.
On 27 Oct 2016, at 23:55, tim Rowledge tim@rowledge.org wrote:
Hi!
Look in platforms/unix/config and try `make`. Fails at configure.ac line 201. Which is weird because it *must* have worked not so many hours ago when I did a completely scratch load of the source tree on this particular machine.
Suggestions welcomed.
See this patch[1] from my 2014 post[2]. I didn't check if it still applies but it is more or less what is needed to make it work with an autoconf from 2012.
holger
[1] http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140913/bc7a... [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2014-September/016489.htm...
On 27-10-2016, at 2:59 PM, Holger Freyther holger@freyther.de wrote:
On 27 Oct 2016, at 23:55, tim Rowledge tim@rowledge.org wrote:
Hi!
Look in platforms/unix/config and try `make`. Fails at configure.ac line 201. Which is weird because it *must* have worked not so many hours ago when I did a completely scratch load of the source tree on this particular machine.
Suggestions welcomed.
See this patch[1] from my 2014 post[2]. I didn't check if it still applies but it is more or less what is needed to make it work with an autoconf from 2012.
I can’t extract anything useful from your files- I download a .bin, extract it and get a cpgz, extract that and get… a .bin!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: WK: Write to Keyboard
On Thu, Oct 27, 2016 at 2:55 PM, tim Rowledge tim@rowledge.org wrote:
I’m trying to make the UnicodePlugin for an x86 linux. You’d think that would be simple enough but in fact the config fails because it has a hard-coded ARAM path in the UnicodePlugin/acinlude.m4 file - probably my fault from a couple of years ago as it happens.
So, add the x86 path (for the glibconfig.h file; I imagine there is a way to make that get worked out automagically - see the CPPFLAGS line in platforms/unix/plugins/UnicodePlugin/acinclude.m4) and rebuild. Except the mvm script doesn’t re-run the configuration build. OK, delete the dratted config.h to force it to re-run autoconf.
Sigh, nothing doing. No change.
Look in platforms/unix/config and try `make`. Fails at configure.ac line 201. Which is weird because it *must* have worked not so many hours ago when I did a completely scratch load of the source tree on this particular machine.
Suggestions welcomed.
The fundamental issue is that we need to ditch autoconf (and cake) from the build process (I'm not saying from development, but from configuring and building a VM).
But ion the short term, 1) fix the path in platforms/unix/plugins/UnicodePlugin/acinclude.m4, commit and push 2) ask someone who has a system that will rebuild configure to do so, and wait for them to do so and commit and push 3) try again with the revised configure script
(configure how do I hate thee? let me count the ways...)
Error output follows -
tim@ubuntu:~/squeak/opensmalltalk-vm/platforms/unix/config$ make configure ./mkacinc > acplugins.m4 + ../vm-display-Quartz/acinclude.m4 + ../vm-display-X11/acinclude.m4 + ../vm-display-custom/acinclude.m4 + ../vm-display-fbdev/acinclude.m4 + ../vm-sound-ALSA/acinclude.m4 + ../vm-sound-MacOSX/acinclude.m4 + ../vm-sound-NAS/acinclude.m4 + ../vm-sound-OSS/acinclude.m4 + ../vm-sound-Sun/acinclude.m4 + ../vm-sound-custom/acinclude.m4 + ../vm-sound-null/acinclude.m4 + ../vm-sound-pulse/acinclude.m4 + ../vm/acinclude.m4 + ../plugins/B3DAcceleratorPlugin/acinclude.m4 + ../plugins/BitBltPlugin/acinclude.m4 + ../plugins/BochsIA32Plugin/acinclude.m4 + ../plugins/BochsX64Plugin/acinclude.m4 + ../plugins/FloatMathPlugin/acinclude.m4 + ../plugins/GdbARMPlugin/acinclude.m4 + ../plugins/IA32ABI/acinclude.m4 + ../plugins/MIDIPlugin/acinclude.m4 + ../plugins/Mpeg3Plugin/acinclude.m4 + ../plugins/PseudoTTYPlugin/acinclude.m4 + ../plugins/UUIDPlugin/acinclude.m4 + ../plugins/UnicodePlugin/acinclude.m4 + ../plugins/UnixOSProcessPlugin/acinclude.m4 + ../plugins/XDisplayControlPlugin/acinclude.m4 aclocal autoconf configure.ac:201: error: possibly undefined macro: AC_PROG_NM If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:219: error: possibly undefined macro: AC_DISABLE_STATIC configure.ac:220: error: possibly undefined macro: AC_PROG_LIBTOOL make: *** [configure] Error 1
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Original Sin is hard to find, but the digitally enhanced version is readily available.
On 27-10-2016, at 4:02 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
The fundamental issue is that we need to ditch autoconf (and cake) from the build process (I'm not saying from development, but from configuring and building a VM).
No word of argument from me. Other than saying it can’t happen soon enough.
But ion the short term,
- fix the path in platforms/unix/plugins/UnicodePlugin/acinclude.m4, commit and push
Well first there’s 0) edit the damn configure script to add the include path and get a working %^$%&^#ing VM. (And woo-hoo! got the configure to actually agree to make the plugin at last)
- ask someone who has a system that will rebuild configure to do so, and wait for them to do so and commit and push
Shouldn’t a ubuntu x86 linux system be able to do that?
- try again with the revised configure script
(configure how do I hate thee? let me count the ways…)
I’d give up. Trying to exhaustively count an uncountable infinity is sure to hurt.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- He has a tenuous grip on the obvious.
On 27-10-2016, at 4:02 PM, Eliot Miranda eliot.miranda@gmail.com wrote: But ion the short term,
- fix the path in platforms/unix/plugins/UnicodePlugin/acinclude.m4, commit and push
Done and appears to be correct in the repository.
- ask someone who has a system that will rebuild configure to do so, and wait for them to do so and commit and push
Please rebuild configure, somebody. Pretty please?
- try again with the revised configure script
I did manage to build a working version by hacking the configure and makefile directly. Which is awful, appalling, dangerous, risky, unwise, unpleasant, wrong, foolish and probably unlawful. But it worked.
Next question - does anyone have objections to adding the ScratchPlugin and UnicodePlugin to the general builds for x86 (and whatever other) builds? I’d suggest external plugins to make it easier to leave them out of any distributions.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Watch out for off-by-one errorss.
On Mon, Oct 31, 2016 at 04:20:48PM -0700, tim Rowledge wrote:
On 27-10-2016, at 4:02 PM, Eliot Miranda eliot.miranda@gmail.com wrote: But ion the short term,
- fix the path in platforms/unix/plugins/UnicodePlugin/acinclude.m4, commit and push
Done and appears to be correct in the repository.
- ask someone who has a system that will rebuild configure to do so, and wait for them to do so and commit and push
Please rebuild configure, somebody. Pretty please?
This has not worked on my Ubuntu laptop PC for quite some time. The newer gcc compiler no longer recognizes a flag used in the old configure script, so rebuilding config seems to be needed. To do that, I tried installing various versions of autotools, and none seemed to be able to rebuild configure on my system. I don't recall the exact symptoms, but nothing that I tried seemed to work. Presumably some updates would be needed in platforms/unix/config if the the autotools build is going to be maintained.
Has anyone else made progress on this?
- try again with the revised configure script
I did manage to build a working version by hacking the configure and makefile directly. Which is awful, appalling, dangerous, risky, unwise, unpleasant, wrong, foolish and probably unlawful. But it worked.
Next question - does anyone have objections to adding the ScratchPlugin and UnicodePlugin to the general builds for x86 (and whatever other) builds? I???d suggest external plugins to make it easier to leave them out of any distributions.
I cannot think of any reason not to do that, as long as they plausibly compile, and run on platforms of interest. That's what external plugins are for :-)
Dave
On Mon, Oct 31, 2016 at 6:06 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Oct 31, 2016 at 04:20:48PM -0700, tim Rowledge wrote:
On 27-10-2016, at 4:02 PM, Eliot Miranda eliot.miranda@gmail.com
wrote:
But ion the short term,
- fix the path in platforms/unix/plugins/UnicodePlugin/acinclude.m4,
commit and push
Done and appears to be correct in the repository.
- ask someone who has a system that will rebuild configure to do so,
and wait for them to do so and commit and push
Please rebuild configure, somebody. Pretty please?
This has not worked on my Ubuntu laptop PC for quite some time. The newer gcc compiler no longer recognizes a flag used in the old configure script, so rebuilding config seems to be needed. To do that, I tried installing various versions of autotools, and none seemed to be able to rebuild configure on my system. I don't recall the exact symptoms, but nothing that I tried seemed to work. Presumably some updates would be needed in platforms/unix/config if the the autotools build is going to be maintained.
Has anyone else made progress on this?
I maintain a 5.3 CentOS installation (as a VM) just for this purpose. I'm /really/ looking forward to being able to nuke it.
- try again with the revised configure script
I did manage to build a working version by hacking the configure and
makefile directly. Which is awful, appalling, dangerous, risky, unwise, unpleasant, wrong, foolish and probably unlawful. But it worked.
Next question - does anyone have objections to adding the ScratchPlugin
and UnicodePlugin to the general builds for x86 (and whatever other) builds? I???d suggest external plugins to make it easier to leave them out of any distributions.
I cannot think of any reason not to do that, as long as they plausibly compile, and run on platforms of interest. That's what external plugins are for :-)
Dave
On 01 Nov 2016, at 02:07, Eliot Miranda eliot.miranda@gmail.com wrote:
I maintain a 5.3 CentOS installation (as a VM) just for this purpose. I'm /really/ looking forward to being able to nuke it.
created a pull request for my old work but didn't run/build using that script.
On 01 Nov 2016, at 14:18, Holger Freyther holger@freyther.de wrote:
created a pull request for my old work but didn't run/build using that script.
any feedback? Having ran autoreconf seems to have fixed a "defect" in the midi plugin (and created a link issue in return).
holger
On 12 Nov 2016, at 21:31, Holger Freyther holger@freyther.de wrote:
Hi guys,
created a pull request for my old work but didn't run/build using that script.
any feedback? Having ran autoreconf seems to have fixed a "defect" in the midi plugin (and created a link issue in return).
A fix for the .ac/m4 files still sits as a pull request without _any_ feedback, the same goes for my FilePlugin changes. Like all of you I am very busy but I try to spend some of my _limited_ time to move things forward and in return I would like to have timely feedback.
cheers holger
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Eliot Miranda -
Holger Freyther -
tim Rowledge