{"thread":{"id":"53499","subject":"Minor portability issues + fixes","startedAt":"2020-05-19T01:16:48Z","lastAt":"2020-05-22T20:03:03Z","messageCount":8,"participants":["Daniel Richard G.","Jeff King","Carlo Marcelo Arenas Belón"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"398172","messageId":"7422404e-7fc8-4961-aae4-3f0adb71bb3a@www.fastmail.com","threadId":"53499","inReplyTo":null,"subject":"Minor portability issues + fixes","fromName":"Daniel Richard G.","fromEmail":"skunk@iskunk.org","sentAt":"2020-05-19T01:15:58Z","receivedAt":"2020-05-19T01:16:48Z","isPatch":false,"sender":{"key":"skunk@iskunk.org","avatar":"https://gravatar.com/avatar/7c998cbd345218d092e71b3fbb736a1e1c572575bff54986bb66474c5a781ade?d=mp&s=160"},"body":"Hello list,\n\nI am building Git 2.26.2 on AIX. A few compilation errors arose, but\nthey are resolvable with a few minor changes that will improve overall\nportability.\n\nThere were a few errors of this form:\n\n    sha1-file.c: In function 'mmap_limit_check':\n    sha1-file.c:940:12: error: 'SIZE_MAX' undeclared (first use in this function)\n    sha1-file.c:940:12: note: each undeclared identifier is reported only once for each function it appears in\n\nSIZE_MAX is defined in stdint.h, and adding that #include fixes this. It\nis likely that this header is being pulled in on other platforms due to\ntransitive dependencies, but that does not occur on AIX.\n\nThe following files need #include<stdint.h>:\n\n    sha1-file.c\n    utf8.c\n    vcs-svn/svndiff.c\n    wrapper.c\n\n(I am not sure of the correct place to add a header like this; I\nhave only verified that adding it to the .c file directly solves\nthe problem.)\n\nThen, at link time, I saw this:\n\n    rm -f xdiff/lib.a && ar rcs xdiff/lib.a xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o xdiff/xmerge.o xdiff/xpatience.o xdiff/xhistogram.o\n    gcc  -D_ALL_SOURCE -D_THREAD_SAFE   -I. -D_LARGE_FILES -DGIT_HOST_CPU=\"\\\"00XXXXXXXXXX\\\"\" -I/nfs/freeport/arch/aix32/include -DNO_CURL -I/nfs/freeport/arch/aix32/include -DNO_OPENSSL -DNO_D_TYPE_IN_DIRENT -DNO_NSEC -Dsockaddr_storage=sockaddr_in6 -DNO_ICONV -DOLD_ICONV -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK -DNO_PTHREADS -DHAVE_PATHS_H -DHAVE_STRINGS_H -DHAVE_CLOCK_GETTIME  -DSNPRINTF_RETURNS_BOGUS -DFREAD_READS_DIRECTORIES -DNO_STRCASESTR -DNO_STRLCPY -DNO_STRTOUMAX -DNO_SETENV -DNO_MKDTEMP -DNO_UNSETENV -DNO_PREAD -DNO_MEMMEM -DINTERNAL_QSORT -Icompat/regex -DFILENO_IS_A_MACRO -DNEED_ACCESS_ROOT_HANDLER -DDEFAULT_EDITOR='\"nano\"' -DDEFAULT_PAGER='\"more\"' -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -o git-credential-store   credential-store.o common-main.o libgit.a xdiff/lib.a  -L/nfs/freeport/arch/aix32/lib /nfs/freeport/arch/aix32/lib -L/nfs/freeport/arch/aix32/lib /nfs/freeport/arch/aix32/lib -lz -lintl\n    ld: 0711-168 SEVERE ERROR: Input file: /nfs/freeport/arch/aix32/lib\n            Input files must be regular files.\n    collect2: error: ld returned 12 exit status\n    Makefile:2456: recipe for target 'git-credential-store' failed\n    gmake: *** [git-credential-store] Error 1\n\nAfter some investigation, I found that this resulted from the following\nconfigure-time determination:\n\n    configure:4774: WARNING: linker does not support runtime path to dynamic libraries\n    (from line 488 of configure.ac)\n\nThe problem is, in this case, CC_LD_DYNPATH is set to an empty value---\nwhich is incorrect, in light of how it is used in the Makefile. Here is\na typical example:\n\n    ifdef ZLIB_PATH\n            BASIC_CFLAGS += -I$(ZLIB_PATH)/include\n            EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH)$(ZLIB_PATH)/$(lib)\n    endif\n    EXTLIBS += -lz\n\nSetting that variable to an empty value causes a bare directory to be\npassed to the linker, which of course then errors out. I would suggest\nsetting it to \"-L\" instead.\n\n(The libraries I am using are all static archives, so I am not hampered\nby a lack of runtime library paths.)\n\n\n--Daniel\n\n\n-- \nDaniel Richard G. || skunk@iSKUNK.ORG\nMy ASCII-art .sig got a bad case of Times New Roman.\n"},{"id":"398175","messageId":"20200519024945.GB70483@coredump.intra.peff.net","threadId":"53499","inReplyTo":"7422404e-7fc8-4961-aae4-3f0adb71bb3a@www.fastmail.com","subject":"Re: Minor portability issues + fixes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-19T02:49:45Z","receivedAt":"2020-05-19T02:49:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 18, 2020 at 09:15:58PM -0400, Daniel Richard G. wrote:\n\n> I am building Git 2.26.2 on AIX. A few compilation errors arose, but\n> they are resolvable with a few minor changes that will improve overall\n> portability.\n> \n> There were a few errors of this form:\n> \n>     sha1-file.c: In function 'mmap_limit_check':\n>     sha1-file.c:940:12: error: 'SIZE_MAX' undeclared (first use in this function)\n>     sha1-file.c:940:12: note: each undeclared identifier is reported only once for each function it appears in\n> \n> SIZE_MAX is defined in stdint.h, and adding that #include fixes this. It\n> is likely that this header is being pulled in on other platforms due to\n> transitive dependencies, but that does not occur on AIX.\n\nAll system defines in Git should be pulled in via git-compat-util.h.\nThat does include stdint.h, but only if NO_INTTYPES_H is defined\n(otherwise we prefer inttypes.h). And POSIX (2004) says:\n\n  The <inttypes.h> header shall include the <stdint.h> header.\n\nBut perhaps that is not so on AIX (it wouldn't be the first time we've\nseen a platform that does not strictly follow POSIX).\n\nDoes building with:\n\n  make NO_INTTYPES_H=YesPlease\n\nwork?\n\nIf so, then perhaps it should be added to the AIX defines in\nconfig.mak.uname.\n\n> The problem is, in this case, CC_LD_DYNPATH is set to an empty value---\n> which is incorrect, in light of how it is used in the Makefile. Here is\n> a typical example:\n> \n>     ifdef ZLIB_PATH\n>             BASIC_CFLAGS += -I$(ZLIB_PATH)/include\n>             EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH)$(ZLIB_PATH)/$(lib)\n>     endif\n>     EXTLIBS += -lz\n> \n> Setting that variable to an empty value causes a bare directory to be\n> passed to the linker, which of course then errors out. I would suggest\n> setting it to \"-L\" instead.\n\nThat would just be redundant with the earlier argument. That might be\nthe easiest way to turn it into a noop, but we can probably do better\nwith $(if) or similar, which would allow somebody to build with:\n\n  make CC_LD_DYNPATH=\n\neven without using the autoconf script.\n\nI do wonder, though, if configure.ac could be extended for AIX to\nsupport whatever syntax the system linker uses for setting the run-path.\nI understand that you don't care either way about this feature, but this\nmight be a good opportunity to fix it.\n\n-Peff\n"},{"id":"398176","messageId":"20200519030440.GB20332@Carlos-MBP","threadId":"53499","inReplyTo":"7422404e-7fc8-4961-aae4-3f0adb71bb3a@www.fastmail.com","subject":"Re: Minor portability issues + fixes","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2020-05-19T03:04:40Z","receivedAt":"2020-05-19T03:04:45Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Mon, May 18, 2020 at 09:15:58PM -0400, Daniel Richard G. wrote:\n> \n> I am building Git 2.26.2 on AIX. A few compilation errors arose, but\n> they are resolvable with a few minor changes that will improve overall\n> portability.\n\nwhich version of AIX is this?\n\n> There were a few errors of this form:\n> \n>     sha1-file.c: In function 'mmap_limit_check':\n>     sha1-file.c:940:12: error: 'SIZE_MAX' undeclared (first use in this function)\n>     sha1-file.c:940:12: note: each undeclared identifier is reported only once for each function it appears in\n\nwe include inttypes.h which is supposed to include stdint.h per POSIX[1]\n\ncould you take a look at that header and see if there is some macro definition\npreventing that to happen?\n\nCarlo\n\n[1] https://pubs.opengroup.org/onlinepubs/009696799/basedefs/inttypes.h.html\n"},{"id":"398177","messageId":"40a42f1d-61bd-46fb-8946-5588df7b044b@www.fastmail.com","threadId":"53499","inReplyTo":"20200519024945.GB70483@coredump.intra.peff.net","subject":"Re: Minor portability issues + fixes","fromName":"Daniel Richard G.","fromEmail":"skunk@iskunk.org","sentAt":"2020-05-19T04:22:00Z","receivedAt":"2020-05-19T04:22:57Z","isPatch":false,"sender":{"key":"skunk@iskunk.org","avatar":"https://gravatar.com/avatar/7c998cbd345218d092e71b3fbb736a1e1c572575bff54986bb66474c5a781ade?d=mp&s=160"},"body":"Hi Jeff,\n\nOn Mon, 2020 May 18 22:49-04:00, Jeff King wrote:\n> \n> All system defines in Git should be pulled in via git-compat-util.h.\n> That does include stdint.h, but only if NO_INTTYPES_H is defined\n> (otherwise we prefer inttypes.h). And POSIX (2004) says:\n> \n>   The <inttypes.h> header shall include the <stdint.h> header.\n> \n> But perhaps that is not so on AIX (it wouldn't be the first time we've\n> seen a platform that does not strictly follow POSIX).\n\nOn AIX 4.3, where I am building, inttypes.h does not #include stdint.h,\nand stdint.h is not present under /usr/include/. (This is an old system\nused for ABI compatibility-testing purposes.)\n\nThis is not general to AIX, however, because on 5.3, both stdint.h and\nits #include are there.\n\nThat said, my build is using GCC 4.7, which provides a modern stdint.h.\nThe GCC tree contains a fixincluded version of inttypes.h, but this also\nlacks the <stdint.h> #include.\n\n> Does building with:\n> \n>   make NO_INTTYPES_H=YesPlease\n> \n> work?\n>\n> If so, then perhaps it should be added to the AIX defines in\n> config.mak.uname.\n\nI've confirmed that this works. But would it not be safe to #include\nboth inttypes.h and stdint.h explicitly if both are present, rather than\ncater to AIX specifically? I could see this similarly arising in, say,\nan old version of Solaris.\n\n> > Setting that variable to an empty value causes a bare directory to be\n> > passed to the linker, which of course then errors out. I would suggest\n> > setting it to \"-L\" instead.\n> \n> That would just be redundant with the earlier argument. That might be\n> the easiest way to turn it into a noop, but we can probably do better\n> with $(if) or similar, which would allow somebody to build with:\n> \n>   make CC_LD_DYNPATH=\n> \n> even without using the autoconf script.\n\nThat is a fair point. CC_LD_DYNPATH is used only a handful of times, so\nthis wouldn't be much more work.\n\n> I do wonder, though, if configure.ac could be extended for AIX to\n> support whatever syntax the system linker uses for setting the run-path.\n> I understand that you don't care either way about this feature, but this\n> might be a good opportunity to fix it.\n\nThis could be a bit complicated, I'm afraid.\n\nThe applicable value for CC_LD_DYNPATH on AIX is \"-Wl,-blibpath:\".\nHowever, have a look at the description for this option in the\nld(1) man page:\n\n       libpath:Path\n            Uses Path as the library path when writing the loader\n            section of the output file. Path is neither checked for\n            validity nor used when searching for libraries specified by\n            the -l flag. Path overrides any library paths generated when\n            the -L flag is used.\n\n            If you do not specify any -L flags, or if you specify the\n            nolibpath option, the default library path information is\n            written in the loader section of the output file. The\n            default library path information is the value of the LIBPATH\n            environment variable if it is defined, and /usr/lib:/lib,\n            otherwise.\n\n(excerpted from an AIX 7.1 system)\n\nThat implies that when you use this option, you must specify not only\nthe path you're interested in, but also /usr/lib:/lib! And when I look\nat an existing AIX build of ours, that makes use of Libtool, I see that\nit is in fact passing in a rather lengthy path for -Wl,-blibpath:, that\nends with \":/usr/lib:/lib\".\n\n\n--Daniel\n\n\n-- \nDaniel Richard G. || skunk@iSKUNK.ORG\nMy ASCII-art .sig got a bad case of Times New Roman.\n"},{"id":"398178","messageId":"bbaacb8f-e2d3-4c4a-98d7-acea0b637081@www.fastmail.com","threadId":"53499","inReplyTo":"20200519030440.GB20332@Carlos-MBP","subject":"Re: Minor portability issues + fixes","fromName":"Daniel Richard G.","fromEmail":"skunk@iskunk.org","sentAt":"2020-05-19T04:26:02Z","receivedAt":"2020-05-19T04:26:59Z","isPatch":false,"sender":{"key":"skunk@iskunk.org","avatar":"https://gravatar.com/avatar/7c998cbd345218d092e71b3fbb736a1e1c572575bff54986bb66474c5a781ade?d=mp&s=160"},"body":"Hi Carlo,\n\nOn Mon, 2020 May 18 23:04-04:00, Carlo Marcelo Arenas Belón wrote:\n> On Mon, May 18, 2020 at 09:15:58PM -0400, Daniel Richard G. wrote:\n> > \n> > I am building Git 2.26.2 on AIX. A few compilation errors arose, but\n> > they are resolvable with a few minor changes that will improve overall\n> > portability.\n> \n> which version of AIX is this?\n\n4.3, believe it or not :-]  This system is used for compatibility\ntesting of a legacy product.\n\n> we include inttypes.h which is supposed to include stdint.h per POSIX[1]\n> \n> could you take a look at that header and see if there is some macro definition\n> preventing that to happen?\n\nThere's no #include at all, and stdint.h is not present under\n/usr/include/. But I am building with GCC 4.7 (as the original\nvendor compiler has outlived its usefulness), and that provides a\nmodern stdint.h.\n\nThe original inttypes.h is fixincluded by GCC, but this did not add the\nstdint.h #include.\n\nAs I remarked to Jeff, would it be kosher to #include both inttypes.h\nand stdint.h if both are present? It seems that most of the time, the\nlatter would be a no-op.\n\n\n--Daniel\n\n\n-- \nDaniel Richard G. || skunk@iSKUNK.ORG\nMy ASCII-art .sig got a bad case of Times New Roman.\n"},{"id":"398238","messageId":"20200520042838.GA102274@coredump.intra.peff.net","threadId":"53499","inReplyTo":"40a42f1d-61bd-46fb-8946-5588df7b044b@www.fastmail.com","subject":"Re: Minor portability issues + fixes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-20T04:28:38Z","receivedAt":"2020-05-20T04:28:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 19, 2020 at 12:22:00AM -0400, Daniel Richard G. wrote:\n\n> > If so, then perhaps it should be added to the AIX defines in\n> > config.mak.uname.\n> \n> I've confirmed that this works. But would it not be safe to #include\n> both inttypes.h and stdint.h explicitly if both are present, rather than\n> cater to AIX specifically? I could see this similarly arising in, say,\n> an old version of Solaris.\n\nYes, as long as we check that both are present, I think that would do\nthe right thing. And the autoconf check could cover that. I don't think\nthere's an easy way to have a general Makefile knob that can check which\nfiles are present, though (and we generally consider the Makefile and\nits knobs to be the primary mechanism; autoconf to turn those knobs is\ngenerally implemented on top).\n\nSo probably we'd want something like (in this order):\n\n  - NEEDS_EXPLICIT_STDINT gets passed from the Makefile into the\n    compiler via -D, which then triggers stdint.h being included\n    unconditionally in git-compat-util.h\n\n  - optionally set that in config.mak.uname for AIX (checking uname_R\n    since it sounds like only old versions need it)\n\n  - add an autoconf rule that sets it, either strictly (when a\n    test-program decides it's needed) or loosely (when we see that it's\n    available at all)\n\nEven just the first one would let you build by setting the knob\nmanually; the rest is gravy on top, if you or somebody else chooses to\ndo it.\n\n> > I do wonder, though, if configure.ac could be extended for AIX to\n> > support whatever syntax the system linker uses for setting the run-path.\n> > I understand that you don't care either way about this feature, but this\n> > might be a good opportunity to fix it.\n> \n> This could be a bit complicated, I'm afraid.\n> \n> The applicable value for CC_LD_DYNPATH on AIX is \"-Wl,-blibpath:\".\n> However, have a look at the description for this option in the\n> ld(1) man page:\n\nOK, gross. :) I agree it's not worth going too far into this rabbit\nhole. I do wonder if you could just be using GNU ld along with gcc, but\nmaybe that's not practical.\n\nYou should be able to build with:\n\n  make CC_LD_DYNPATH=-L\n\nas a workaround, but it would be nice if the Makefile handled this\ncorrectly. It looks like CC_LD_DYNPATH gets used in a lot of places, so\nI suspect we'd want a Makefile function to help out. Something like:\n\n\n  # usage: $(call linker_lib,PATH)\n  # Create linker args for looking for libraries in PATH at both link-time\n  # and run-time.\n  linker_lib = -L$1 $(if $(CC_LD_DYNPATH),$(CC_LD_DYNPATH)$1)\n\nwhich would allow:\n\n  EXTLIBS += $(call linker_lib,$(LIBPCREDIR)/$(lib))\n\netc. This would be our first foray into Makefile functions, but I think\nwe've determined that most platforms have a recent enough GNU make for\nit to be OK (and we already require GNU make).\n\n-Peff\n"},{"id":"398326","messageId":"86f751ac-b7c1-43fd-ada5-a8e2e9c4ebc9@www.fastmail.com","threadId":"53499","inReplyTo":"20200520042838.GA102274@coredump.intra.peff.net","subject":"Re: Minor portability issues + fixes","fromName":"Daniel Richard G.","fromEmail":"skunk@iskunk.org","sentAt":"2020-05-21T04:29:18Z","receivedAt":"2020-05-21T04:30:19Z","isPatch":false,"sender":{"key":"skunk@iskunk.org","avatar":"https://gravatar.com/avatar/7c998cbd345218d092e71b3fbb736a1e1c572575bff54986bb66474c5a781ade?d=mp&s=160"},"body":"On Wed, 2020 May 20 00:28-04:00, Jeff King wrote:\n>\n> > I've confirmed that this works. But would it not be safe to #include\n> > both inttypes.h and stdint.h explicitly if both are present, rather than\n> > cater to AIX specifically? I could see this similarly arising in, say,\n> > an old version of Solaris.\n> \n> Yes, as long as we check that both are present, I think that would do\n> the right thing. And the autoconf check could cover that. I don't think\n> there's an easy way to have a general Makefile knob that can check which\n> files are present, though (and we generally consider the Makefile and\n> its knobs to be the primary mechanism; autoconf to turn those knobs is\n> generally implemented on top).\n\nOkay, I see, so the whole phalanx of HAVE_BLAH_H symbols from Autoconf\nisn't available.\n\n> So probably we'd want something like (in this order):\n> \n>   - NEEDS_EXPLICIT_STDINT gets passed from the Makefile into the\n>     compiler via -D, which then triggers stdint.h being included\n>     unconditionally in git-compat-util.h\n> \n>   - optionally set that in config.mak.uname for AIX (checking uname_R\n>     since it sounds like only old versions need it)\n> \n>   - add an autoconf rule that sets it, either strictly (when a\n>     test-program decides it's needed) or loosely (when we see that it's\n>     available at all)\n> \n> Even just the first one would let you build by setting the knob\n> manually; the rest is gravy on top, if you or somebody else chooses to\n> do it.\n\nHmm... that's a fairly specific knob, which I would think is less than\nideal. The rest is reasonable, but would have to be written in terms\nof the knob.\n\nI can put something together, knowing that this is the approach you'd\nwant to see, but it'll need some more work. Eventually, I'll need to get\nGit up and running on a few other old systems I have here, so that will\nundoubtedly figure into it.\n\nThanks for sketching out how this should work, however; this is helpful\nto keep in mind.\n\n> > The applicable value for CC_LD_DYNPATH on AIX is \"-Wl,-blibpath:\".\n> > However, have a look at the description for this option in the\n> > ld(1) man page:\n> \n> OK, gross. :) I agree it's not worth going too far into this rabbit\n> hole. I do wonder if you could just be using GNU ld along with gcc, but\n> maybe that's not practical.\n\nUsing the GNU linker can help in some cases, and hurt in others. We try\nto avoid it unless necessary.\n\n> You should be able to build with:\n> \n>   make CC_LD_DYNPATH=-L\n> \n> as a workaround\n\nYep, this works handily as a no-op :)\n\n> but it would be nice if the Makefile handled this correctly. It looks\n> like CC_LD_DYNPATH gets used in a lot of places, so I suspect we'd\n> want a Makefile function to help out. Something like:\n> \n>   # usage: $(call linker_lib,PATH)\n>   # Create linker args for looking for libraries in PATH at both link-time\n>   # and run-time.\n>   linker_lib = -L$1 $(if $(CC_LD_DYNPATH),$(CC_LD_DYNPATH)$1)\n> \n> which would allow:\n> \n>   EXTLIBS += $(call linker_lib,$(LIBPCREDIR)/$(lib))\n> \n> etc. This would be our first foray into Makefile functions, but I think\n> we've determined that most platforms have a recent enough GNU make for\n> it to be OK (and we already require GNU make).\n\nWhy not just a variable to wrap the conditional? Something like\n\n    CC_LD_DYNPATH_flag = $(if $(CC_LD_DYNPATH),$(CC_LD_DYNPATH),-L)\n\n    ...\n\n    EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH_flag)$(ZLIB_PATH)/$(lib)\n\nMakefile functions are quite powerful, but they feel like a sledgehammer\nto this fly. (I've used them in the past to generate Make rules\nprogrammatically. It wasn't pretty, but it sure beat writing out\nmakefile fragments and then include-ing them afterward!)\n\n\n--Daniel\n\n\n-- \nDaniel Richard G. || skunk@iSKUNK.ORG\nMy ASCII-art .sig got a bad case of Times New Roman.\n"},{"id":"398436","messageId":"20200522200300.GA2160187@coredump.intra.peff.net","threadId":"53499","inReplyTo":"86f751ac-b7c1-43fd-ada5-a8e2e9c4ebc9@www.fastmail.com","subject":"Re: Minor portability issues + fixes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-22T20:03:00Z","receivedAt":"2020-05-22T20:03:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 21, 2020 at 12:29:18AM -0400, Daniel Richard G. wrote:\n\n> > So probably we'd want something like (in this order):\n> > \n> >   - NEEDS_EXPLICIT_STDINT gets passed from the Makefile into the\n> >     compiler via -D, which then triggers stdint.h being included\n> >     unconditionally in git-compat-util.h\n> > \n> >   - optionally set that in config.mak.uname for AIX (checking uname_R\n> >     since it sounds like only old versions need it)\n> > \n> >   - add an autoconf rule that sets it, either strictly (when a\n> >     test-program decides it's needed) or loosely (when we see that it's\n> >     available at all)\n> > \n> > Even just the first one would let you build by setting the knob\n> > manually; the rest is gravy on top, if you or somebody else chooses to\n> > do it.\n> \n> Hmm... that's a fairly specific knob, which I would think is less than\n> ideal. The rest is reasonable, but would have to be written in terms\n> of the knob.\n\nYeah, it is. I do wonder if just setting the existing NO_INTTYPES_H is a\nsimpler solution for your case (since it sounds like that works). If you\nwant to tweak the knob for older AIX in config.mak.uname, that would be\nfine (or if you think other people aren't likely to be building on the\nplatform, maybe tweak your own \"make\" invocation and let this\nconversation serve to document for anybody else).\n\n> > but it would be nice if the Makefile handled this correctly. It looks\n> > like CC_LD_DYNPATH gets used in a lot of places, so I suspect we'd\n> > want a Makefile function to help out. Something like:\n> > \n> >   # usage: $(call linker_lib,PATH)\n> >   # Create linker args for looking for libraries in PATH at both link-time\n> >   # and run-time.\n> >   linker_lib = -L$1 $(if $(CC_LD_DYNPATH),$(CC_LD_DYNPATH)$1)\n> > \n> > which would allow:\n> > \n> >   EXTLIBS += $(call linker_lib,$(LIBPCREDIR)/$(lib))\n> > \n> > etc. This would be our first foray into Makefile functions, but I think\n> > we've determined that most platforms have a recent enough GNU make for\n> > it to be OK (and we already require GNU make).\n> \n> Why not just a variable to wrap the conditional? Something like\n> \n>     CC_LD_DYNPATH_flag = $(if $(CC_LD_DYNPATH),$(CC_LD_DYNPATH),-L)\n> \n>     ...\n> \n>     EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH_flag)$(ZLIB_PATH)/$(lib)\n\nI was trying to actually remove the argument, rather than turn it into a\nduplicate \"-L\". But you're probably right that it's not worth the\neffort.\n\nI think we could just normalize an empty CC_LD_DYNPATH to \"-L\" in the\nsame variable, and then we wouldn't even have to change the sites which\nreference it.\n\n-Peff\n"}]}