From: Robert K. <rl...@al...> - 2020-03-23 02:46:51
|
045790c384b96d6e28651e982bcea1aedd1c7da0 broke the build with gcc (clang works): 2020-03-23T02:02:22+0000 CC check_duplicate_printers.test.o 2020-03-23T02:02:22+0000 check_duplicate_printers.test.c: In function ‘main’: 2020-03-23T02:02:22+0000 check_duplicate_printers.test.c:40:3: error: implicit declaration of function ‘putenv’; did you mean ‘setenv’? [-Werror=implicit-function-declaration] 2020-03-23T02:02:22+0000 putenv("STP_CHECK_DUPLICATE_PRINTERS=TRUE"); 2020-03-23T02:02:22+0000 ^~~~~~ 2020-03-23T02:02:22+0000 setenv -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Solomon P. <pi...@sh...> - 2020-03-23 02:57:35
Attachments:
signature.asc
|
On Sun, Mar 22, 2020 at 10:46:38PM -0400, Robert Krawitz wrote: > 045790c384b96d6e28651e982bcea1aedd1c7da0 broke the build with gcc > (clang works): > 2020-03-23T02:02:22+0000 CC check_duplicate_printers.test.o > 2020-03-23T02:02:22+0000 check_duplicate_printers.test.c: In function ‘main’: > 2020-03-23T02:02:22+0000 check_duplicate_printers.test.c:40:3: error: implicit declaration of function ‘putenv’; did you mean ‘setenv’? [-Werror=implicit-function-declaration] > 2020-03-23T02:02:22+0000 putenv("STP_CHECK_DUPLICATE_PRINTERS=TRUE"); > 2020-03-23T02:02:22+0000 ^~~~~~ > 2020-03-23T02:02:22+0000 setenv Hmm. I test-compiled this before committed. Granted, I did so with a modern system. Upon further inspection it appears that in spite of putenv() being part of POSIX-2001, it looks like one needs to define _SVID_SOURCE with glibc older than v2.19 (early 2014). Unfortunately I don't have a test system old enough for me to make sure this fix is sufficient.. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
From: Robert K. <rl...@al...> - 2020-03-23 12:35:41
|
On Sun, 22 Mar 2020 22:57:22 -0400, Solomon Peachy wrote: > > --===============0683292360179802852== > Content-Type: multipart/signed; micalg=pgp-sha512; > protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" > Content-Disposition: inline > > --EeQfGwPcQSOJBaQU > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, Mar 22, 2020 at 10:46:38PM -0400, Robert Krawitz wrote: >> 045790c384b96d6e28651e982bcea1aedd1c7da0 broke the build with gcc >> (clang works): > >> 2020-03-23T02:02:22+0000 CC check_duplicate_printers.test.o >> 2020-03-23T02:02:22+0000 check_duplicate_printers.test.c: In function =E2=80=98main': >> 2020-03-23T02:02:22+0000 check_duplicate_printers.test.c:40:3: error: implicit declaration of function =E2=80=98putenv'; did you mean =E2=80=98setenv'? [-Werror=implicit-function-declaration] >> 2020-03-23T02:02:22+0000 putenv("STP_CHECK_DUPLICATE_PRINTERS=TRUE"); >> 2020-03-23T02:02:22+0000 ^~~~~~ >> 2020-03-23T02:02:22+0000 setenv > > Hmm. I test-compiled this before committed. Granted, I did so with a > modern system. This is also a modern system. > Upon further inspection it appears that in spite of putenv() being > part of POSIX-2001, it looks like one needs to define _SVID_SOURCE > with glibc older than v2.19 (early 2014). It looks like _XOPEN_SOURCE is the more generic way to do it. Perhaps it should be conditionalized on Windows? > Unfortunately I don't have a test system old enough for me to make sure > this fix is sufficient.. -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Solomon P. <pi...@sh...> - 2020-03-23 14:58:48
Attachments:
signature.asc
|
On Mon, Mar 23, 2020 at 08:35:31AM -0400, Robert Krawitz wrote: > It looks like _XOPEN_SOURCE is the more generic way to do it. Perhaps > it should be conditionalized on Windows? I added stuff to autoconf to test for setenv(), and the code now only uses putenv() if the former is unavailable. BTW, I'm now at the point where libgutenprint compiles cleanly under mingw. libgutenprintui is up next. (I'm not sure how far I want to take this Windows diversion. I'd like to get the CUPS filter and PPD generator to run, but that relies on libcups which doesn't have a convenient mingw port yet..) - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
From: Michael S. <ms...@ms...> - 2020-03-23 15:20:21
|
Solomon, > On Mar 23, 2020, at 10:58 AM, Solomon Peachy <pi...@sh...> wrote: > > On Mon, Mar 23, 2020 at 08:35:31AM -0400, Robert Krawitz wrote: >> It looks like _XOPEN_SOURCE is the more generic way to do it. Perhaps >> it should be conditionalized on Windows? > > I added stuff to autoconf to test for setenv(), and the code now only uses > putenv() if the former is unavailable. > > BTW, I'm now at the point where libgutenprint compiles cleanly under > mingw. libgutenprintui is up next. > > (I'm not sure how far I want to take this Windows diversion. I'd like > to get the CUPS filter and PPD generator to run, but that relies on > libcups which doesn't have a convenient mingw port yet..) Fortunately, libcups builds natively on Windows, although I exclusively dwvelop any Windows stuff (when I have to...) in Visual Studio so I'm not sure where the CUPS configure script sits WRT MingW builds right now. The code itself will build cleanly. ________________________ Michael Sweet |
From: Solomon P. <pi...@sh...> - 2020-03-28 01:17:22
Attachments:
signature.asc
|
On Mon, Mar 23, 2020 at 11:02:20AM -0400, Michael Sweet wrote: > Fortunately, libcups builds natively on Windows, although I > exclusively dwvelop any Windows stuff (when I have to...) in Visual > Studio so I'm not sure where the CUPS configure script sits WRT MingW > builds right now. The code itself will build cleanly. Looks like mingw pukes in multiple places when trying to build libcups, and trying to resolve that has turned into a rabbit hole. If I can't quickly find a preubilt DLL that will make mingw happy, I'll just shelve this little lark in favor of continuing to refactor the backends into soemething more easily integrated into the printer application always-on paradigm.. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |