Skip to contentSkip to conversation

ghostscript-native: Ensure the sys/time/h fix is applied for native builds

PATCH In review Richard Purdie 2 participants 5 messages Nov 25, 2011 – Nov 27, 2011

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ghostscript-native: Ensure the sys/time/h fix is applied for native builds

On my system, the sys/time.h header is in a subdir off /usr/include which causes a build failure. Apply the target CFLAGS fix to native builds as well to address this.

---

meta/recipes-extended/ghostscript/ghostscript_9.04.bb +1 -0
index d444810..86d5ef2 100644
@@ -40,6 +40,7 @@ EXTRA_OECONF = "--without-x --with-system-libtiff --without-jbig2dec --without-j
 # http://bugs.ghostscript.com/show_bug.cgi?id=692443
 # http://bugs.ghostscript.com/show_bug.cgi?id=692426
 CFLAGS += "-DHAVE_SYS_TIME_H=1"
+BUILD_CFLAGS += "-DHAVE_SYS_TIME_H=1"
 
 inherit autotools
 
#1 lore raw
Quoted 3 lines · Richard Purdie

On my system, the sys/time.h header is in a subdir off /usr/include which causes a build failure. Apply the target CFLAGS fix to native builds as well to address this.

hmmm I thought CFLAGS would be automtically translated with BBCLASSEXTEND = "native"

Quoted 23 lines

---

meta/recipes-extended/ghostscript/ghostscript_9.04.bb +0 -0
index d444810..86d5ef2 100644
@@ -40,6 +40,7 @@ EXTRA_OECONF = "--without-x --with-system-libtiff --without-jbig2dec --without-j
  # http://bugs.ghostscript.com/show_bug.cgi?id=692443
  # http://bugs.ghostscript.com/show_bug.cgi?id=692426

 CFLAGS += "-DHAVE_SYS_TIME_H=1"
+BUILD_CFLAGS += "-DHAVE_SYS_TIME_H=1"

 inherit autotools

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#2 lore raw
Quoted 8 lines · Khem Raj
Quoted 3 lines · Richard Purdie

On my system, the sys/time.h header is in a subdir off /usr/include which causes a build failure. Apply the target CFLAGS fix to native builds as well to address this.

hmmm I thought CFLAGS would be automtically translated with BBCLASSEXTEND = "native"

For native recipes, CFLAGS is replaced by BUILD_CFLAGS...

Cheers,

Richard

#3 lore raw
Quoted 11 lines · Richard Purdie
Quoted 8 lines · Khem Raj
Quoted 3 lines · Richard Purdie

On my system, the sys/time.h header is in a subdir off /usr/include which causes a build failure. Apply the target CFLAGS fix to native builds as well to address this.

hmmm I thought CFLAGS would be automtically translated with BBCLASSEXTEND = "native"

For native recipes, CFLAGS is replaced by BUILD_CFLAGS...

yes I see. A little niggle I was thinking of is that at present for a target recipe if something gets changed in CFLAGS or TARGET_CFLAGS that makes to the compile phase as combined CFLAGS

for native we rewrite CFLAGS = BUILD_CFLAGS

So either CFLAGS += BUILD_FLAGS for native CFLAGS += TARGET_CFLAGS will make it consistent or just override CFLAGS with BUILD_CFLAGS or TARGET_CFLAGS depending on recipe type

Quoted 11 lines

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#4 lore raw
Quoted 18 lines · Khem Raj
Quoted 11 lines · Richard Purdie
Quoted 8 lines · Khem Raj
Quoted 3 lines · Richard Purdie

On my system, the sys/time.h header is in a subdir off /usr/include which causes a build failure. Apply the target CFLAGS fix to native builds as well to address this.

hmmm I thought CFLAGS would be automtically translated with BBCLASSEXTEND = "native"

For native recipes, CFLAGS is replaced by BUILD_CFLAGS...

yes I see. A little niggle I was thinking of is that at present for a target recipe if something gets changed in CFLAGS or TARGET_CFLAGS that makes to the compile phase as combined CFLAGS

Quoted 5 lines

for native we rewrite CFLAGS = BUILD_CFLAGS

So either CFLAGS += BUILD_FLAGS for native CFLAGS += TARGET_CFLAGS will make it consistent or just override CFLAGS with BUILD_CFLAGS or TARGET_CFLAGS depending on recipe type

We could do with looking into addressing this inconsistency, yes.

Cheers,

Richard