Cannot compile picscale in OpenEmbedded

[barryk]

Hi guys,
As I have posted about recently, I compile nearly all the packages of EasyOS in my fork of OpenEmbedded.

Including vovchik's great little 'picscale', which is a vital part of all pups. Version 0.1b is what I use, here:

distro.ibiblio.org/quirky/quirky6/sources/alphabetical/p/picscale-0.1b.tar.bz2

I have compiled it without problem with bacon 3.0.2, for i686, x86_64 and arm targets. Recently, I bumped to bacon 3.7.2, and picscale compiled OK for a aarch64 target. Using gcc 6.3.0, glibc 2.25 and bash 4.3.30.

Last night I did a build in OE for target x86_64 (nocona), and picscale failed to compile.

The compile function in the OE picscale recipe is:

do_compile () {
   mkdir -p temp1
   # -n convert to C only, -a rebuild libbacon.a, -p preserve temporary files,
   # -y automatically delete temporary files, -x extract gettext strings...
   ${TMPDIR}/bacon.sh -y -n -p -d temp1 picscale.bac
   cd temp1
${CC} -fPIC -c picscale.bac.c ${CFLAGS}
${CC} -o picscale picscale.bac.o -L. -lbacon -lm  -ldl ${LDFLAGS}
cd ..
}

The compile log reports this:

Converting 'picscale.bac'... 119 0K
/mnt/sdb1/projects/oe/oe-quirky/buildPC/tmp-glibc/bacon.sh: line 176: ${hash_my_msg__b2c__string_var)}: bad substitution
/mnt/sdb1/projects/oe/oe-quirky/buildPC/tmp-glibc/bacon.sh: eval: line 283: syntax error near unexpected token `)'
/mnt/sdb1/projects/oe/oe-quirky/buildPC/tmp-glibc/bacon.sh: eval: line 283: `hash_my_msg__b2c__string_var)___SHOW_ERROR=${TYPE}'

Converting 'picscale.bac'... 120 0K

It does generate a 'picscale' executable, however, the above error message is picked up by OE and it stops the build.

I checked the compile log for the aarch64 build, it does not have that error.

So, I looked at that line 119 in picscale.bac:

SUB SHOW_ERROR(STRING my_msg$))
' -----------
PRINT my_msg$
PRINT argv_err$
END SUB

...hey, that looks like an extra unwanted ")" on the end.

Alright, but how come the aarch64 build succeeded? It is the same packages, bacon 3.7.2 etc.

Also, the old bacon 3.0.2 never complained.

Any thoughts?

[barryk]

Ah, have just realized.

For the aarch64 build, I used bacon 3.5.4, which compiled picscale ok.

Later, I bumped bacon to 3.7.2, and compiled for aarch64, but did not recompile picscale.

So, bacon 3.0.2 and 3.5.4 did not report that syntax error, just ignored the extra ")".

Anyway, I have fixed it in OE, put in a 'sed' line to remove the ")".

[vovchik]

Dear Barry,

I'm glad that picscale is useful. I looked at my sources after seeing your message and found version 1c, which also can handle the svg format. I have attached the source.

With kind regards,
vovchik

Attachments:

picscale.bac.tar.gz (2.75 KB)

[barryk]

Hi Vovchik,
I am just about to update the recipe in my fork of OpenEmbedded. Before that though, did a complete build and it gave an error for picscale at the "QA" step, querying whether the license is valid.

The recipe is here:

github.com/bkauler/oe-qky-src/blob/master/quirky/meta-quirky/recipes-quirky/picscale/picscale_0.1b.bb

I had assigned "GPLv2", with the checksum of picscale.bac, which worked OK before, but something has changed, now QA is querying it. Probably it wants a proper license file.

Is it OK with you if I assign picscale.bac as GPLv2, and include a generic license file with the source package?

Also, I will bump the source to 0.1c, and the HOMEPAGE as this forum thread.

[vovchik]

Dear Barry,

Please use whatever license file is easiest and best for our common purposes. It is all OK with me. The main thing is that we get a clean build and and satisfy the build mechanism with minimum effort.

With kind regards,
vovchik

[barryk]

vovchik
It has been awhile!
I have your picscale 0.1c source. If I cross-compile in OpenEmbedded, it segfaults when try to use it (though, just "picscale --help" works). Compile it in a running system, it works.

This is an old problem, and I would really like to find out why. Here is what happens:

# ./picscale -i email48.png -o email128.png 128 128 9
ERROR: signal for SEGMENTATION FAULT received - memory invalid or array out of bounds? Try to compile the program with TRAP LOCAL to find the cause.

The source has "TRAP LOCAL", which doesn't seem to help.

Here is the build recipe in OE:

# Recipe created by recipetool
# recipetool create -o picscale_0.1c.bb http://distro.ibiblio.org/easyos/source/oe/pyro/picscale-0.1c.tar.gz
# 20220809 attempting to fix compile, using old bacon 2.4.0.
# 20220811 now have bacon 4.5

HOMEPAGE = "http://basic-converter.proboards.com/thread/1014/compile-picscale-openembedded"
SUMMARY = "Scale png images from the command line."

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"

PV = "0.1c"
SRC_URI = "http://distro.ibiblio.org/easyos/source/oe/pyro/picscale-${PV}.tar.gz"

SRC_URI[md5sum] = "fb58172c96973da7d80e37fbe93d2735"
SRC_URI[sha256sum] = "e5d97400f32c7cf8ce4ba0d19ae6bdd246477d01864b948527add6349096c0e5"

DEPENDS = "gtk+ gdk-pixbuf bash bacon-native"

do_configure () {
true
}

do_compile () {
mkdir -p build
bacon -d build -c "${CC}" -o "${CFLAGS}" -l "${LDFLAGS}" picscale.bac
}

do_install () {
   install -d ${D}/usr/bin
   install -m755 build/picscale ${D}/usr/bin
}

Here are the variables $CC, $CFLAGS and $LDFLAGS:

CC=x86_64-poky-linux-gcc  -m64 -march=nocona -mtune=nocona -mno-sse3 -mfpmath=sse -fstack-protector-strong  \
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security \
--sysroot=/mnt/build/oe-builds/oe-quirky/build-amd64/tmp/work/nocona-64-poky-linux/picscale/0.1c-r10/recipe-sysroot

CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types \
-fmacro-prefix-map=/mnt/build/oe-builds/oe-quirky/build-amd64/tmp/work/nocona-64-poky-linux/picscale/0.1c-r10=/usr/src/debug/picscale/0.1c-r10 \
-fdebug-prefix-map=/mnt/build/oe-builds/oe-quirky/build-amd64/tmp/work/nocona-64-poky-linux/picscale/0.1c-r10=/usr/src/debug/picscale/0.1c-r10 \
-fdebug-prefix-map=/mnt/build/oe-builds/oe-quirky/build-amd64/tmp/work/nocona-64-poky-linux/picscale/0.1c-r10/recipe-sysroot=                      -fdebug-prefix-map=/mnt/build/oe-builds/oe-quirky/build-amd64/tmp/work/nocona-64-poky-linux/picscale/0.1c-r10/recipe-sysroot-native=

LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now

The source is here:

distro.ibiblio.org/easyos/source/oe/pyro/picscale-0.1c.tar.gz

Do you have any suggestions where the likely culprit is in the code?

[vovchik]

Dear Barry,

Nice to hear from you, too. I found my picscale (v. 1d) source and have attached it. It compiled fine (and also ran properly) with the following line:


bacon -l -no-pie -o -fno-pie -o -Wno-implicit -o -Os -o -fdata-sections -o -ffunction-sections -o -Wl,--gc-sections -l -s picscale.bac


Does that help at all?

With kind regards,
vovchik

Attachments:

picscale1d.bac.tar.gz (2.64 KB)

[barryk]

Thanks for that later source!

Not using OpenEmbedded for now, just compiling in the host system (EasyOS 4.3), with bacon 4.5.

Firstly, compiling like this:

# bacon -d build picscale.bac

...I get segfault when try to use it, exactly as reported above.

# ./picscale -i pet48.png -o pet128.png 128 128 9
ERROR: signal for SEGMENTATION FAULT received - memory invalid or array out of bounds? Try to compile the program with TRAP LOCAL to find the cause.

Secondly, compiling it as you have suggested:

# bacon -l -no-pie -o -fno-pie -o -Wno-implicit -o -Os -o -fdata-sections -o -ffunction-sections -o -Wl,--gc-sections -l -s picscale.bac

And it works!

# ./picscale -i pet48.png -o pet128.png 128 128 9
Warning: width result not divisible by 2
Warning: height result not divisible by 2
File pet128.png created.
Original image: pet48.png
New dimensions (w x h): 128 x 128
Quality of new image: 9

At first, I thought those options of yours were to make the executable smaller, which it does.
However, the lack of one or more of them breaks picscale.

Do you know which one is essential for picscale to work?

[Pjot]

Hi Barry,

You are right of course, the 'picscale' program from vovchik should work with a regular compile as well.

Strangely, Valgrind never complains in case of a regular compile, but with 'gdb' we can see the cause:

(gdb) run -i foto.png -o foto.png 128 128 9
Starting program: /home/peter/programming/bacon/picscale -i foto.png -o foto.png 128 128 9
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78c2785 in gdk_pixbuf_get_width () from /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
(gdb) where
#0  0x00007ffff78c2785 in gdk_pixbuf_get_width () at /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#1  0x000055555555b6d9 in PROCESS_DATA () at /home/peter/programming/bacon/picscale.PROCESS_DATA.h:37
#2  0x000055555555cd85 in main (argc=8, argv=0x7fffffffe098) at picscale.bac.c:236
(gdb) exit


The imported functions define their arguments as 'int' while in fact these should be an opaque 'long' (or even better: 'void*').

51 IMPORT "gdk_pixbuf_get_width(int)" FROM Gdk$ TYPE int
52 IMPORT "gdk_pixbuf_get_height(int)" FROM Gdk$ TYPE int


But after changing the argument type to 'long' it works fine:

51 IMPORT "gdk_pixbuf_get_width(long)" FROM Gdk$ TYPE int
52 IMPORT "gdk_pixbuf_get_height(long)" FROM Gdk$ TYPE int


Please find attached the improved code.

Best regards
Peter

Attachments:

picscale.bac.gz (2.57 KB)

[barryk]

Peter,
Thanks for finding the cause!

The picscale package that I use in EasyOS was compiled years ago, as had segfaults later on.
Back then, it would have been a "regular" compile.

For the record, I have gcc 9.3.0, and these are the default parameters:

# echo "" | cc -v -E - 2>&1 | grep cc1
/usr/libexec/gcc/x86_64-poky-linux/9.3.0/cc1 -E -quiet -v - -mtune=generic -march=nocona

I have bumped the source package to 0.1e, uploaded here:

distro.ibiblio.org/easyos/source/alphabetical/p/

[Pjot]

Thanks Barry,

Please feel free to come back to this forum in case you run into other problems with BaCon.

Best regards
Peter

[vovchik]

Dear Peter (and Barry),

Thanks. Two bugs found and nicely squashed.

With kind regards,
vovchik

[bigbass]

Hello barryk Peter and vovchik

glad to see you got it working!

some code built on 32 bit arch
sometimes needs a little push to keep it
going on x86_64

*the code still works on the rpi3
Joe