package/pcre: install headers in legacy location
PATCH 1/1 package/pcre: install headers in legacy location
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.
---
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(+)
package/pcre/pcre.mk +8 -0
@@ -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))
Signature · 1 line
1.9.1
PATCH 1/1 package/pcre: install headers in legacy location
Hi Yann, all,
Le 13/12/2014 18:08, Yann E. MORIN a ?crit :
Quoted 5 lines
nmap is looking for pcre headers in
pcre/pcre.hwhich our current version of pcre does not populates.So, just create those as symlinks to the actual headers.
Quoted 8 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Romain Naour <[email protected]>---
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;
Best regards,
Signature · 8 lines
Romain Naour OPEN WIDE Ing?nierie - Paris 23/25, rue Daviel| 75013 PARIS http://ingenierie.openwide.fr Le blog des technologies libres et embarqu?es : http://www.linuxembedded.fr
PATCH 1/1 package/pcre: install headers in legacy location
In reply to Yann E. MORINDear Yann E. MORIN,
Quoted 4 lines · Yann E. MORIN
nmap is looking for pcre headers in
pcre/pcre.hwhich 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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/pcre: install headers in legacy location
Thomas, All,
On 2014-12-21 23:19 +0100, Thomas Petazzoni spake thusly:
Quoted 8 lines · Yann E. MORIN
Quoted 4 lines
nmap is looking for pcre headers in
pcre/pcre.hwhich 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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 package/pcre: install headers in legacy location
Dear Yann E. MORIN,
Quoted 11 lines · Yann E. MORIN
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/pcre: install headers in legacy location
In reply to Yann E. MORINAll,
On 2014-12-13 18:08 +0100, Yann E. MORIN spake thusly:
Quoted 7 lines
nmap is looking for pcre headers in
pcre/pcre.hwhich our current version of pcre does not populates.So, just create those as symlinks to the actual headers.
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Romain Naour <[email protected]>
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>
#endifHAVE_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.
Quoted 25 lines
--- package/pcre/pcre.mk | 8 ++++++++ 1 file changed, 8 insertions(+)package/pcre/pcre.mk +8
-0@@ -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))Signature · 1 line
1.9.1
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'