You are not logged in.
Hello!
I have an issue with AUR epson-inkjet-printer-escpr2.
The last version 1.2.31-1 built just fine, but then failed ever since. And I have no idea as to why this is the case...
Normally I just run the same sequence in my ~/AUR/epson-inkjet-printer-escpr2 directory as regular user:
cd ~/AUR/epson-inkjet-printer-escpr2
git pull
makepkg
To install, I then run this as root:
pacman -U $HOME/AUR/epson-inkjet-printer-escpr2/epson-inkjet-printer-escpr2-$VERSION-x86_64.pkg.tar.zst
(For the arbitrary path I use the correct $HOME, and obviously I substitute $VERSION with the one I have built...)
Now, jeadorf informed me of build failures. I tested this on my system again, and the same now happened reproducible on my system. I even started out clean:
cd ~/AUR ; mv epson-inkjet-printer-escpr2 epson-inkjet-printer-escpr2.previous
git clone https://aur.archlinux.org/epson-inkjet-printer-escpr2.git
When I then run makepkg it downloads the package and the build fails.
Why did it run successfully the first time? I have the package to prove it, and it's also installed on my system at this very moment.
And why has it failed ever since? Was there a change in the tool chain in the last days? I didn't notice one...
Help appreciated.
Last edited by andret (2025-05-02 19:24:19)
Offline
I tested vitaliikuzhdin's suggestion from https://aur.archlinux.org/packages/epso … nt-1022317 that they posted in the meantime. I added the following to the PKGBUILD
export CFLAGS="${CFLAGS} -std=gnu17"
and it indeed builds. The info they linked https://gcc.gnu.org/gcc-15/porting_to.html#c23 looks related, too.
I have no further info, I just dutifully tested vitaliikuzhdin's hint.
Offline
Thanks!
I wanted to add this to the autoconf stuff and luckily I found this: https://stackoverflow.com/questions/234 … ation-make
Should be in the AUR repo now...
Again thanks for reaching out, reporting and helping to fix!
Offline
Did you intend to remove Arch's CFLAGS by setting CFLAGS="-std=gnu17' instead of CFLAGS="$CFLAGS -std=gnu17"?
Online
Did you intend to remove Arch's CFLAGS by setting CFLAGS="-std=gnu17' instead of CFLAGS="$CFLAGS -std=gnu17"?
No, I did not. I wanted to *add* them... Seems, autoconf is not the right place then...
Offline
You can either any of:
./configure --prefix=/usr \
--with-cupsfilterdir=/usr/lib/cups/filter \
--with-cupsppddir=/usr/share/ppd \
CFLAGS="$CFLAGS -std=gnu17"
CFLAGS="$CFLAGS -std=gnu17" ./configure --prefix=/usr \
--with-cupsfilterdir=/usr/lib/cups/filter \
--with-cupsppddir=/usr/share/ppd
CFLAGS+=' -std=gnu17'
./configure --prefix=/usr \
--with-cupsfilterdir=/usr/lib/cups/filter \
--with-cupsppddir=/usr/share/ppd
Edit:
As the issue is introduced by bug_x86_64.patch providing a prototype for SendStartJob that does not match I would just change the prototype:
diff --git a/bug_x86_64.patch b/bug_x86_64.patch
index ab244dd..f344c3c 100644
--- a/bug_x86_64.patch
+++ b/bug_x86_64.patch
@@ -28,7 +28,7 @@ index d53e091..5bb2a5f 100644
+#include "xfifo.h"
+
+extern EPS_ERR_CODE SetupJobAttrib (const EPS_JOB_ATTRIB*);
-+extern EPS_ERR_CODE SendStartJob ();
++extern EPS_ERR_CODE SendStartJob (int);
+extern EPS_ERR_CODE PrintBand (const EPS_UINT8*, EPS_UINT32, EPS_UINT32*);
#define WIDTH_BYTES(bits) (((bits) + 31) / 32 * 4)
Last edited by loqs (2025-05-02 21:37:02)
Online
You can either any of:
./configure --prefix=/usr \ --with-cupsfilterdir=/usr/lib/cups/filter \ --with-cupsppddir=/usr/share/ppd \ CFLAGS="$CFLAGS -std=gnu17"
I did try this one, but then the build failed...
CFLAGS+=' -std=gnu17' ./configure --prefix=/usr \ --with-cupsfilterdir=/usr/lib/cups/filter \ --with-cupsppddir=/usr/share/ppd
Can you tell me why some people use export VAR=... while other use just VAR=... and what the difference is? I've now put "export CFLAGS=..." in PKGBUILD, but I would rather know if there is a right way to do this for the future.
Edit:
As the issue is introduced by bug_x86_64.patch providing a prototype for SendStartJob that does not match I would just change the prototype:diff --git a/bug_x86_64.patch b/bug_x86_64.patch index ab244dd..f344c3c 100644 --- a/bug_x86_64.patch +++ b/bug_x86_64.patch @@ -28,7 +28,7 @@ index d53e091..5bb2a5f 100644 +#include "xfifo.h" + +extern EPS_ERR_CODE SetupJobAttrib (const EPS_JOB_ATTRIB*); -+extern EPS_ERR_CODE SendStartJob (); ++extern EPS_ERR_CODE SendStartJob (int); +extern EPS_ERR_CODE PrintBand (const EPS_UINT8*, EPS_UINT32, EPS_UINT32*); #define WIDTH_BYTES(bits) (((bits) + 31) / 32 * 4)
I'll try to incorporate this and will do so tomorrow, after testing everything once again... Thank you so much for your help!
Offline
loqs wrote:You can either any of:
./configure --prefix=/usr \ --with-cupsfilterdir=/usr/lib/cups/filter \ --with-cupsppddir=/usr/share/ppd \ CFLAGS="$CFLAGS -std=gnu17"
I did try this one, but then the build failed...
Retested with this change and it is building for me:
diff --git a/PKGBUILD b/PKGBUILD
index cdf4811..c97b9b8 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -30,7 +30,7 @@ build() {
./configure --prefix=/usr \
--with-cupsfilterdir=/usr/lib/cups/filter \
--with-cupsppddir=/usr/share/ppd \
- CFLAGS='-std=gnu17'
+ CFLAGS="$CFLAGS -std=gnu17"
make
}
loqs wrote:CFLAGS+=' -std=gnu17' ./configure --prefix=/usr \ --with-cupsfilterdir=/usr/lib/cups/filter \ --with-cupsppddir=/usr/share/ppd
Can you tell me why some people use export VAR=... while other use just VAR=... and what the difference is? I've now put "export CFLAGS=..." in PKGBUILD, but I would rather know if there is a right way to do this for the future.
The reason to export the variable is so that it will be inherited by sub-processes. It makes no difference for variables that makepkg already exports in build() check() and package() such as CFLAGS. It does not do any harm either it is simply redundant.
Online
Yes, CFLAGS as argument to ./configure works when double quotes are used. I had accidentally used single quotes:
./configure ... CFLAGS='-std=gnu77' works, but
./configure ... CFLAGS='$CFLAGS -std=gnu77' does NOT, while
./configure ... CFLAGS="$CFLAGS -std=gnu77" works, again.
Sorry, my bad.
As the issue is introduced by bug_x86_64.patch providing a prototype for SendStartJob that does not match I would just change the prototype …
In the AUR I've now reverted to the PKGBUILD before the issue, but I've incorporated your change in the patch and rebased it to the current escpr2 version, 1.2.31-1.
Again, BIG thanks for your help!
Last edited by andret (2025-05-03 20:10:56)
Offline