My build environment is described here, I am working through the table trying to promote the builds from 2.4.0 to 2.5.0.
I now build with
LANG=C ./package.sh 2.5.0
This is done in a newly created docker for each operating system with the dependencies loaded into the environment. It does not build as root or actually install in the docker. The build process produces packages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I think I have got to the bottom of it.
I isolated the problem to just being --enable-french, building default English or the other languages caused no problem.
I seem to have solved it by setting LANG=C before each build.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most seem to now be working with the addition of LANG=C except "almalinux" 8.6 on x86_64. This fails in the same place but the first one to fail with en_US.UTF-8. However rocky 8.6 does work.
With the use of LANG=C I have got all the Linux builds that I want upgraded to 2.5.0.
It still fails on almalinux 8.6 even though it works on rocky 8.6.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I notice that I often see ( this example was from opensuse 15.3) when processing the help files
An invalid multi-byte character was found in the input.
Is this because the build system file character sets are different to the operating system default character sets? Given the source files ar under source control and are a known format, shouldn't the buildsystem itself be specifying any multibyte character set encoding for it's own source rather than accepting it from the environment? For example if all source files are UTF8 then all processing should be using UTF8 and not dependent on host platform.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Debian 12 (currently still sid) I had the same error, the fix was to include en_US.UTF-8 in the locales.
Runsudo dpkg-reconfigure locales and also select it.
However, I ran ./configure --enable-german if that is relevant.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By default only C/en_US languages are built.
To build additional languages, you need to use the corresponding --enable-<lang> option - see configure --help.</lang>
Thanks. I tried that and got
I am able to build 2.5.0 default with just en_US.UTF-8 and also complete 2.4.0.
Last edit: Roger Brown 2022-07-31
On 7/30/22 18:12, Roger Brown wrote:
That doesn't help me much... What OS? Version? Do you have all of the
correct UTF-8 locales installed?
This builds fine on 4 versions of Ubuntu, CENTOS, freebsd 12, freebsd13,
netbsd92 and openbsd7...
-jon
--
Jon Trulson
"The less you know, the more you believe."
-- Bono
Related
Tickets:
#1442.4.0 builds cleanly on these environments...
I consistently get the dtdocbook2sdl fatal error while doing fr_FR.UTF-8 on
ubuntu 20.04
debian 10
opensuse 15.4
kali
I have success on
debian 11
ubuntu 22.04
centos 8
Could you provide more details about your OS? Architecture, version, etc.. It seems OK on Debian 10.
My build environment is a docker container for each platform and architecture set up with just the compiler tools and the required libraries.
I don't do a build and install, I do a build and create an RPM or DEB package, then that is installed on another machine.
I think it it is a build environment problem.
I have it now working with the four additional languages if I set LANG=C before doing the compilation.
Please check your locale settings. Unset LC_ALL and try again.
Thanks, but no diffence, LC_ALL is already not set in my docker environments.
My build environment is described here, I am working through the table trying to promote the builds from 2.4.0 to 2.5.0.
I now build with
This is done in a newly created docker for each operating system with the dependencies loaded into the environment. It does not build as root or actually install in the docker. The build process produces packages.
Hi, I think I have got to the bottom of it.
I isolated the problem to just being --enable-french, building default English or the other languages caused no problem.
I seem to have solved it by setting LANG=C before each build.
... and can now build with all four additional languages enabled. Good work!
Most seem to now be working with the addition of LANG=C except "almalinux" 8.6 on x86_64. This fails in the same place but the first one to fail with en_US.UTF-8. However rocky 8.6 does work.
https://sourceforge.net/p/rhubarb-pi/wiki/pkg-cdesktopenv/
With the use of LANG=C I have got all the Linux builds that I want upgraded to 2.5.0.
It still fails on almalinux 8.6 even though it works on rocky 8.6.
I notice that I often see ( this example was from opensuse 15.3) when processing the help files
Is this because the build system file character sets are different to the operating system default character sets? Given the source files ar under source control and are a known format, shouldn't the buildsystem itself be specifying any multibyte character set encoding for it's own source rather than accepting it from the environment? For example if all source files are UTF8 then all processing should be using UTF8 and not dependent on host platform.
Please try this MR:
https://sourceforge.net/p/cdesktopenv/code/merge-requests/51/
That worked on Debian x86_64 bullseye in a docker.
On Debian 12 (currently still sid) I had the same error, the fix was to include en_US.UTF-8 in the locales.
Run
sudo dpkg-reconfigure locales
and also select it.However, I ran
./configure --enable-german
if that is relevant.I created a script to create a debian package to enable all the required locales
https://sourceforge.net/p/rhubarb-pi/code/HEAD/tree/trunk/pkg/rhubarb-pi-locales/package.sh