| Message ID | 1418490513-10957-1-git-send-email-yann.morin.1998@free.fr |
|---|---|
| State | Rejected |
| Headers | show |
Hi Yann, all, Le 13/12/2014 18:08, Yann E. MORIN a écrit : > nmap is looking for pcre headers in pcre/pcre.h which our current > version of pcre does not populates. > > So, just create those as symlinks to the actual headers. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > Cc: Romain Naour <romain.naour@openwide.fr> > > --- > Note: this is not fixing anything for now, because the error in nmap is > hidden by another error. But this is relaticvely easy to fix, so here we > go... ;-) > --- Confirmed by the nmap's configure output before this patch... checking pcre/pcre.h usability... no checking pcre/pcre.h presence... no checking for pcre/pcre.h... no ... and after this patch: checking pcre/pcre.h usability... yes checking pcre/pcre.h presence... yes checking for pcre/pcre.h... yes But it seems that the bundled nmap's libpcre is not build even with this patch. In nmap's Makefile, "pcre_build" is not part of "all" target. But for consistency with --with-libpcre="$(STAGING_DIR)/usr", let's the pcre checking works... (Maybe some other packages are looking for pcre in /usr/include/pcre/ directory). So; Acked-by: Romain Naour <romain.naour@openwide.fr> Best regards,
Dear Yann E. MORIN, On Sat, 13 Dec 2014 18:08:33 +0100, Yann E. MORIN wrote: > nmap is looking for pcre headers in pcre/pcre.h which our current > version of pcre does not populates. > > So, just create those as symlinks to the actual headers. Do we want this, or instead do we want to fix nmap and other pcre users to use the new location? Thanks, Thomas
Thomas, All, On 2014-12-21 23:19 +0100, Thomas Petazzoni spake thusly: > On Sat, 13 Dec 2014 18:08:33 +0100, Yann E. MORIN wrote: > > nmap is looking for pcre headers in pcre/pcre.h which our current > > version of pcre does not populates. > > > > So, just create those as symlinks to the actual headers. > > Do we want this, or instead do we want to fix nmap and other pcre users > to use the new location? I don;t know. One the one hand, we woudl certainly prefer to fix packages to use the new location, so we can eventually get rid of our hacks to make them build when we eventually update them. On the other hand, I'm afraid this could be an endless hide-and-seek game, which would take us quite some efforts to upstream our patches, especially for packages that may still want to build on older systems with the old layout... However, for now, the only offender in this respect is nmap, so I can try to fix it and upstream the fix. Regards, Yann E. MORIN.
Dear Yann E. MORIN, On Tue, 23 Dec 2014 12:21:36 +0100, Yann E. MORIN wrote: > One the one hand, we woudl certainly prefer to fix packages to use the > new location, so we can eventually get rid of our hacks to make them > build when we eventually update them. > > On the other hand, I'm afraid this could be an endless hide-and-seek > game, which would take us quite some efforts to upstream our patches, > especially for packages that may still want to build on older systems > with the old layout... > > However, for now, the only offender in this respect is nmap, so I can > try to fix it and upstream the fix. Hard to take a decision without having an idea on the number of affected packages. So far, if only nmap has been detected by the autobuilders, it seems like not that many packages are broken by this issue, and therefore fixing nmap seems to be the right solution. Best regards, Thomas
All, On 2014-12-13 18:08 +0100, Yann E. MORIN spake thusly: > nmap is looking for pcre headers in pcre/pcre.h which our current > version of pcre does not populates. > > So, just create those as symlinks to the actual headers. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > Cc: Romain Naour <romain.naour@openwide.fr> I've marked this patch as "Rejected" in Patchwork, because it is in fact not needed. nmap's configure.ac has: AC_CHECK_HEADERS(pcre/pcre.h) which seems to imply it is only checking for pcre/pcre.h but that is not the case. A little bit above, we can see: AC_CHECK_HEADER(pcre.h, AC_CHECK_LIB(pcre, pcre_version, [have_pcre=yes ]), [AC_CHECK_HEADER(pcre/pcre.h, [AC_CHECK_LIB(pcre, pcre_version, [have_pcre=yes])] )] ) which means it also checks for just pcre.h which we have. But that is misleading, as only pcre/pcre.h appears in the configure log, as Romain quoted in his reply. But then, the code that includes pcre/pcre.h (present in two files) has this construct: #ifdef HAVE_PCRE_PCRE_H # include <pcre/pcre.h> #else # include <pcre.h> #endif HAVE_PCRE_PCRE_H is defined by AC_CHECK_HEADERS(pcre/pcre.h), so if it does not find pcre/pcre.h, it falls back to including pcre.h. So, this patch is in fact not needed. Regards, Yann E. MORIN. > --- > package/pcre/pcre.mk | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/package/pcre/pcre.mk b/package/pcre/pcre.mk > index 4ff7abd..f2cf02d 100644 > --- a/package/pcre/pcre.mk > +++ b/package/pcre/pcre.mk > @@ -22,5 +22,13 @@ PCRE_CONF_OPTS += $(if $(BR2_PACKAGE_PCRE_32),--enable-pcre32,--disable-pcre32) > PCRE_CONF_OPTS += $(if $(BR2_PACKAGE_PCRE_UTF),--enable-utf,--disable-utf) > PCRE_CONF_OPTS += $(if $(BR2_PACKAGE_PCRE_UCP),--enable-unicode-properties,--disable-unicode-properties) > > +define PCRE_LEGACY_PATHS > + $(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include/pcre > + for h in $(STAGING_DIR)/usr/include/pcre*.h; do \ > + ln -sf ../$${h##*/} $(STAGING_DIR)/usr/include/pcre/ || exit 1; \ > + done > +endef > +PCRE_POST_INSTALL_STAGING_HOOKS += PCRE_LEGACY_PATHS > + > $(eval $(autotools-package)) > $(eval $(host-autotools-package)) > -- > 1.9.1 >
diff --git a/package/pcre/pcre.mk b/package/pcre/pcre.mk index 4ff7abd..f2cf02d 100644 --- a/package/pcre/pcre.mk +++ b/package/pcre/pcre.mk @@ -22,5 +22,13 @@ PCRE_CONF_OPTS += $(if $(BR2_PACKAGE_PCRE_32),--enable-pcre32,--disable-pcre32) PCRE_CONF_OPTS += $(if $(BR2_PACKAGE_PCRE_UTF),--enable-utf,--disable-utf) PCRE_CONF_OPTS += $(if $(BR2_PACKAGE_PCRE_UCP),--enable-unicode-properties,--disable-unicode-properties) +define PCRE_LEGACY_PATHS + $(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include/pcre + for h in $(STAGING_DIR)/usr/include/pcre*.h; do \ + ln -sf ../$${h##*/} $(STAGING_DIR)/usr/include/pcre/ || exit 1; \ + done +endef +PCRE_POST_INSTALL_STAGING_HOOKS += PCRE_LEGACY_PATHS + $(eval $(autotools-package)) $(eval $(host-autotools-package))
nmap is looking for pcre headers in pcre/pcre.h which our current version of pcre does not populates. So, just create those as symlinks to the actual headers. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@openwide.fr> --- Note: this is not fixing anything for now, because the error in nmap is hidden by another error. But this is relaticvely easy to fix, so here we go... ;-) --- package/pcre/pcre.mk | 8 ++++++++ 1 file changed, 8 insertions(+)