HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
Thanks.
bruce
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape Das.Linux@gmx.de wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel bruce.oneel@pckswarms.ch wrote: HI, On my arm64 system the unicode plugin is disabled. But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted. What debian package is it trying to find the cflags for? It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks. bruce
Hi Bruce --
What debian package is it trying to find the cflags for?
glib, pango, cairo, ... something like this:
UNICODE_PLUGIN_CFLAGS = -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 UNICODE_PLUGIN_LIBS = -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo
Best,
Marcel Am 28.09.2021 13:18:22 schrieb Bruce O'Neel bruce.oneel@pckswarms.ch: Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel wrote: HI, On my arm64 system the unicode plugin is disabled. But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted. What debian package is it trying to find the cflags for? It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks. bruce
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel <bruce.oneel@pckswarms.ch [mailto:bruce.oneel@pckswarms.ch]> wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
On Sep 28, 2021, at 5:39 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Bruce --
What debian package is it trying to find the cflags for?
glib, pango, cairo, ... something like this:
UNICODE_PLUGIN_CFLAGS = -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 UNICODE_PLUGIN_LIBS = -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo
We will have to elaborate the makefiles to remove the processor specificity. An if-then-elif-then Chan is needed fir the processor specificity. arm64 and x86_64 are only two of several possibilities here.
I am building the Virtend vm on Apple silicon and x86_64 and have to do similarly.
But more concerning is the glibc version. The entire vm must use the same glibc version and so if we want to be able to specify it we need a variable name and that needs to be used across the entire vm build.
Again let me suggest that using static makefiles is far easier and faster to implement and debug this kind of flexibility rather than the autoconf nightmare we endure now.
Best, Marcel
Am 28.09.2021 13:18:22 schrieb Bruce O'Neel bruce.oneel@pckswarms.ch:
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi
On 28. Sep 2021, at 16:39, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sep 28, 2021, at 5:39 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Bruce --
What debian package is it trying to find the cflags for?
glib, pango, cairo, ... something like this:
UNICODE_PLUGIN_CFLAGS = -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 UNICODE_PLUGIN_LIBS = -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo
We will have to elaborate the makefiles to remove the processor specificity. An if-then-elif-then Chan is needed fir the processor specificity. arm64 and x86_64 are only two of several possibilities here.
What you see there was provided by pkg-config. it is linux-specifc and necessary due to glib (not to be confused with glibc)
these path are not in the repo.
I am building the Virtend vm on Apple silicon and x86_64 and have to do similarly.
But more concerning is the glibc version. The entire vm must use the same glibc version and so if we want to be able to specify it we need a variable name and that needs to be used across the entire vm build.
Again let me suggest that using static makefiles is far easier and faster to implement and debug this kind of flexibility rather than the autoconf nightmare we endure now.
They confuse the hell out of me. And break profoundly once any of the involved 3drpartys (linux,distro,windors,apple) changes any path…
-t
Best, Marcel
Am 28.09.2021 13:18:22 schrieb Bruce O'Neel bruce.oneel@pckswarms.ch:
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
On Sep 28, 2021, at 7:47 AM, Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 28. Sep 2021, at 16:39, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sep 28, 2021, at 5:39 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Bruce --
What debian package is it trying to find the cflags for?
glib, pango, cairo, ... something like this:
UNICODE_PLUGIN_CFLAGS = -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 UNICODE_PLUGIN_LIBS = -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo
We will have to elaborate the makefiles to remove the processor specificity. An if-then-elif-then Chan is needed fir the processor specificity. arm64 and x86_64 are only two of several possibilities here.
What you see there was provided by pkg-config. it is linux-specifc and necessary due to glib (not to be confused with glibc)
these path are not in the repo.
I am building the Virtend vm on Apple silicon and x86_64 and have to do similarly.
But more concerning is the glibc version. The entire vm must use the same glibc version and so if we want to be able to specify it we need a variable name and that needs to be used across the entire vm build.
Again let me suggest that using static makefiles is far easier and faster to implement and debug this kind of flexibility rather than the autoconf nightmare we endure now.
They confuse the hell out of me.
Perhaps. You can learn.
And break profoundly once any of the involved 3drpartys (linux,distro,windors,apple) changes any path…
That’s simply not so. The information about the various oaths has to be somewhere. It isn’t magic. The information is either in autoconf, necessitating a rebuild, and dealing with the two phase build, or in a makefiles. Putting variants in a makefiles has the advantage that one can see the variants in context. For example, a makefile in platforms/unix/plugins/UnicodePlugin is a much more natural place to put and find variants in building Unicode than in magic inside platforms/unix/conf.
-t
Best, Marcel
Am 28.09.2021 13:18:22 schrieb Bruce O'Neel bruce.oneel@pckswarms.ch:
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi Eliot --
Cmake might be a step into the right direction, considering low-effort, cross-platform compatibility.
If you want a single person to be able to maintain all platforms, then a single representation would be nice. Sure, static Makefiles could be just that. Unfortunately, static makefiles often entail too much redundancy and brittle, hard-coded magic. It's very easy to make mistakes.
If you want specific shepherds for each platform, then we would keep autoconf for Linux because that's what one would use on Linux, right? Anyway...
Cmake sounds like the better compromise for our situation. Static makefiles do not. Ian already sketched a Cmake config for the SqueakVM before the beginning of Cog. So, we wouldn't even have to start at zero.
Best, Marcel Am 01.10.2021 06:06:11 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Sep 28, 2021, at 7:47 AM, Tobias Pape wrote:
Hi
On 28. Sep 2021, at 16:39, Eliot Miranda wrote:
On Sep 28, 2021, at 5:39 AM, Marcel Taeumel wrote:
Hi Bruce --
What debian package is it trying to find the cflags for?
glib, pango, cairo, ... something like this:
UNICODE_PLUGIN_CFLAGS = -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 UNICODE_PLUGIN_LIBS = -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo
We will have to elaborate the makefiles to remove the processor specificity. An if-then-elif-then Chan is needed fir the processor specificity. arm64 and x86_64 are only two of several possibilities here.
What you see there was provided by pkg-config. it is linux-specifc and necessary due to glib (not to be confused with glibc)
these path are not in the repo.
I am building the Virtend vm on Apple silicon and x86_64 and have to do similarly.
But more concerning is the glibc version. The entire vm must use the same glibc version and so if we want to be able to specify it we need a variable name and that needs to be used across the entire vm build.
Again let me suggest that using static makefiles is far easier and faster to implement and debug this kind of flexibility rather than the autoconf nightmare we endure now.
They confuse the hell out of me.
Perhaps. You can learn.
And break profoundly once any of the involved 3drpartys (linux,distro,windors,apple) changes any path…
That’s simply not so. The information about the various oaths has to be somewhere. It isn’t magic. The information is either in autoconf, necessitating a rebuild, and dealing with the two phase build, or in a makefiles. Putting variants in a makefiles has the advantage that one can see the variants in context. For example, a makefile in platforms/unix/plugins/UnicodePlugin is a much more natural place to put and find variants in building Unicode than in magic inside platforms/unix/conf.
-t
Best, Marcel
Am 28.09.2021 13:18:22 schrieb Bruce O'Neel :
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape wrote: Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi
On 1. Oct 2021, at 06:05, Eliot Miranda eliot.miranda@gmail.com wrote:
[…]
They confuse the hell out of me.
Perhaps. You can learn.
Admittedly, I have not yet spend as many years looking at them. The experience with Self's static-makefile-based build-system was enough however to see for me that, unless your environment gives you enough help (Eg, OpenBSDs default makefile includes), you'll have a hard time collecting all necessary information in a tractable way.
And break profoundly once any of the involved 3drpartys (linux,distro,windors,apple) changes any path…
That’s simply not so. The information about the various oaths has to be somewhere.
Have you seen the demise of apple's developer documentation? It's a clusterf$$#. Other people have and can spend way more time on figuring all that stuff out. And they do. And they create things like autoconf, cmake, gyp, scons, etc.
It isn’t magic. The information is either in autoconf, necessitating a rebuild, and dealing with the two phase build, or in a makefiles. Putting variants in a makefiles has the advantage that one can see the variants in context. For example, a makefile in platforms/unix/plugins/UnicodePlugin is a much more natural place to put and find variants in building Unicode than in magic inside platforms/unix/conf.
My change to platforms/unix/conf for UnicodePlugin is solely due to the way Ian wrote the plugin-support macros, as it did not foresee the multitude of ways that some libs need their Compiler Parameters be set up.
Look at pangocairo. Since it depends on glib, you won't get around pkg-config. Why? because look at the cflags necessary to build against pangocairo on my Ubuntu 20.04:
% pkg-config --cflags pangocairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16
These paths all will be different for: distri (different even debian/ubuntu), abi, platform, whatdoiknow.
Thus, the simple "find library to link against for plugin" macro of Ians does not work. Incidentally, when he ditched autoconf for cmake, these things got quite a bit easier...
So, hardcoding those in a static makefile is not possible. One _could_ use pkg-config in a makefile, but then we are in dynamicland again. And when we are in dynamicland already, I really don't see value in scattering this information all over 214 mvm files, and 240 makefiles.
===========
What I do when I touch autoconf, is to try to make broken things work in a way that fits the system as is.
I am not to argue anything here. I'll try to fit in.
-tobias
-t
Best, Marcel
Am 28.09.2021 13:18:22 schrieb Bruce O'Neel bruce.oneel@pckswarms.ch:
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
HI,
On my arm64 system the unicode plugin is disabled.
But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi,
It works perfectly with the last commit!
Thanks.
cheers
bruce
On 2021-09-28T13:18:11.000+02:00, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
------------------------- Hi, Nope, you are right, I am one commit behind. I'll check that out and build. Thanks! bruce On 2021-09-28T13:06:40.000+02:00, Tobias Pape Das.Linux@gmx.de wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel bruce.oneel@pckswarms.ch wrote: HI, On my arm64 system the unicode plugin is disabled. But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted. What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks. bruce
vm-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
Eliot Miranda -
Marcel Taeumel -
Tobias Pape