vdr: questions regarding cplusplus.patch

vdr: questions regarding cplusplus.patch

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

Dear Henning and list,


packaging VDR for OE you added cplusplus.patch [1] to be applied. I am
trying to get the patches upstream, but I have some questions.

Is it correct, that the two changes have the following goals?

1. Instead of using the C headers which are deprecated use the headers
provided by C++ as mentioned for example in [2].
2. You changed `canonicalize_file_name(FileName);` to
`realpath(FileName,NULL);`. Is that because OE just support Linux and
not GNU/Hurd for example [3]?
3. I do not understand why a lot of headers are included in tools.h and
tools.c. But I have to look that up in some reference.


Thanks,

Paul


[1] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/vdr/files/cplusplus.patch
[2] http://en.wikipedia.org/wiki/Stdarg.h
[3] http://mail.gnome.org/archives/gtk-devel-list/2002-October/msg00111.html

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: vdr: questions regarding cplusplus.patch

[Rolf Leggewie]

Paul Menzel wrote:
> packaging VDR for OE you added cplusplus.patch [1] to be applied. I am
> trying to get the patches upstream, but I have some questions.

great, thank you.

Please document the status as per
http://wiki.openembedded.org/index.php/Push_patches_upstream

Re: vdr: questions regarding cplusplus.patch

[Henning Heinold]

On Sun, Jan 10, 2010 at 08:53:18AM +0100, Paul Menzel wrote:
> Dear Henning and list,
> 
> 
> packaging VDR for OE you added cplusplus.patch [1] to be applied. I am
> trying to get the patches upstream, but I have some questions.
> 
> Is it correct, that the two changes have the following goals?
> 
> 1. Instead of using the C headers which are deprecated use the headers
> provided by C++ as mentioned for example in [2].
> 2. You changed `canonicalize_file_name(FileName);` to
> `realpath(FileName,NULL);`. Is that because OE just support Linux and
> not GNU/Hurd for example [3]?
> 3. I do not understand why a lot of headers are included in tools.h and
> tools.c. But I have to look that up in some reference.
> 

Hi Paul,

with gcc 4.x and 4.4 c++ is stricter at including headers the right way.
So you need to include a couple of headers, because some functions
are not found. You can test it in oe with using binutils 2.20 and
gcc-4.4.2 and leave the patches out.

The problem with canonicalize_file_name was, that the function too
wasn't found with gcc-4.4.2. So I googled and found that
canonicalize_file_name(FileName) is the same as realpath(FileName,NULL),
but realpath was found.

I hope this clears some stuff.

Bye Henning

Re: vdr: questions regarding cplusplus.patch

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Am Sonntag, den 10.01.2010, 13:39 +0100 schrieb Henning Heinold:
> On Sun, Jan 10, 2010 at 08:53:18AM +0100, Paul Menzel wrote:
> > packaging VDR for OE you added cplusplus.patch [1] to be applied. I am
> > trying to get the patches upstream, but I have some questions.
> > 
> > Is it correct, that the two changes have the following goals?
> > 
> > 1. Instead of using the C headers which are deprecated use the headers
> > provided by C++ as mentioned for example in [2].
> > 2. You changed `canonicalize_file_name(FileName);` to
> > `realpath(FileName,NULL);`. Is that because OE just support Linux and
> > not GNU/Hurd for example [3]?
> > 3. I do not understand why a lot of headers are included in tools.h and
> > tools.c. But I have to look that up in some reference.
>
> with gcc 4.x and 4.4 c++ is stricter at including headers the right way.
> So you need to include a couple of headers, because some functions
> are not found. You can test it in oe with using binutils 2.20 and
> gcc-4.4.2 and leave the patches out.
> 
> The problem with canonicalize_file_name was, that the function too
> wasn't found with gcc-4.4.2. So I googled and found that
> canonicalize_file_name(FileName) is the same as realpath(FileName,NULL),
> but realpath was found.
> 
> I hope this clears some stuff.

Dear Henning,


thank your for your explanation.

I tried to reproduce that on my Debian Sid/unstable system with

        $ g++ --version
        g++ (Debian 4.4.2-8) 4.4.2
        $ ld --version # binutils 2.20-4
        GNU ld (GNU Binutils for Debian) 2.20
        $ git clone git://git.gekrumbel.de/vdr.git
        $ cd vdr
        $ make

and did not get any warnings.

I will try to reproduce this in OE but have to read up on how to change
the versions in my `local.conf`.


Thanks,

Paul

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: vdr: questions regarding cplusplus.patch

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 2967 bytes --]

Am Sonntag, den 10.01.2010, 21:47 +0100 schrieb Paul Menzel:
> Am Sonntag, den 10.01.2010, 13:39 +0100 schrieb Henning Heinold:
> > On Sun, Jan 10, 2010 at 08:53:18AM +0100, Paul Menzel wrote:
> > > packaging VDR for OE you added cplusplus.patch [1] to be applied. I am
> > > trying to get the patches upstream, but I have some questions.
> > > 
> > > Is it correct, that the two changes have the following goals?
> > > 
> > > 1. Instead of using the C headers which are deprecated use the headers
> > > provided by C++ as mentioned for example in [2].
> > > 2. You changed `canonicalize_file_name(FileName);` to
> > > `realpath(FileName,NULL);`. Is that because OE just support Linux and
> > > not GNU/Hurd for example [3]?
> > > 3. I do not understand why a lot of headers are included in tools.h and
> > > tools.c. But I have to look that up in some reference.
> >
> > with gcc 4.x and 4.4 c++ is stricter at including headers the right way.
> > So you need to include a couple of headers, because some functions
> > are not found. You can test it in oe with using binutils 2.20 and
> > gcc-4.4.2 and leave the patches out.
> > 
> > The problem with canonicalize_file_name was, that the function too
> > wasn't found with gcc-4.4.2. So I googled and found that
> > canonicalize_file_name(FileName) is the same as realpath(FileName,NULL),
> > but realpath was found.
> > 
> > I hope this clears some stuff.
>
> I tried to reproduce that on my Debian Sid/unstable system with
> 
>         $ g++ --version
>         g++ (Debian 4.4.2-8) 4.4.2
>         $ ld --version # binutils 2.20-4
>         GNU ld (GNU Binutils for Debian) 2.20
>         $ git clone git://git.gekrumbel.de/vdr.git
>         $ cd vdr
>         $ make
> 
> and did not get any warnings.
> 
> I will try to reproduce this in OE but have to read up on how to change
> the versions in my `local.conf`.

Dear Henning,


could please you send me your `local.conf` so that I can reproduce this
please? Putting

        PREFERRED_VERSION_binutils               = "2.20"
        PREFERRED_VERSION_binutils-cross         = "2.20"
        PREFERRED_VERSION_binutils-cross-sdk     = "2.20"
        
        PREFERRED_VERSION_gcc                    = "4.4.2"
        PREFERRED_VERSION_gcc-cross              = "4.4.2"
        PREFERRED_VERSION_gcc-cross-sdk          = "4.4.2"
        PREFERRED_VERSION_gcc-cross-initial      = "4.4.2"
        PREFERRED_VERSION_gcc-cross-intermediate = "4.4.2"

in my `local.conf` and running `bitbake vdr` gave me an error in
`do_compile` for `libcap_1.10.bb`.

        arm-angstrom-linux-gnueabi-ld -soname libcap.so.1 -x -shared -o libcap.so.1.10 cap_alloc.o cap_proc.o cap_extint.o cap_flag.o cap_text.o cap_sys.o
        arm-angstrom-linux-gnueabi-ld: cap_text.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC


Thanks,

Paul

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

[vdr] TARGET_CXXFLAGS do not include CXX_FLAGS from Makefile (was: vdr: questions regarding cplusplus.patch)

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 6763 bytes --]

Dear OE hackers,


Am Montag, den 11.01.2010, 23:42 +0100 schrieb Paul Menzel:

[…]

> Putting
> 
>         PREFERRED_VERSION_binutils               = "2.20"
>         PREFERRED_VERSION_binutils-cross         = "2.20"
>         PREFERRED_VERSION_binutils-cross-sdk     = "2.20"
>         
>         PREFERRED_VERSION_gcc                    = "4.4.2"
>         PREFERRED_VERSION_gcc-cross              = "4.4.2"
>         PREFERRED_VERSION_gcc-cross-sdk          = "4.4.2"
>         PREFERRED_VERSION_gcc-cross-initial      = "4.4.2"
>         PREFERRED_VERSION_gcc-cross-intermediate = "4.4.2"
> 
> in my `local.conf` and running `bitbake vdr` gave me an error in
> `do_compile` for `libcap_1.10.bb`.
> 
>         arm-angstrom-linux-gnueabi-ld -soname libcap.so.1 -x -shared -o libcap.so.1.10 cap_alloc.o cap_proc.o cap_extint.o cap_flag.o cap_text.o cap_sys.o
>         arm-angstrom-linux-gnueabi-ld: cap_text.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC

I opened a new thread for this [2].

Anyways compiling the plugins for VDR in `do_install` [3]

        do_install () {
              oe_runmake 'DESTDIR=${D}' \
                         'PREFIX=${prefix}' \
                         'CONFDIR=${sysconfdir}/vdr' \
                         'VIDEODIR=/var/lib/vdr/video' \
                         'PLUGINLIBDIR=${PLUGINDIR}' \
                         'LOCDIR=${datadir}/locale' \
                         install
        }

I also get the same error which I did not get before with GCC 4.1.1.

        $ more log.do_install.28829
        NOTE: make -e MAKEFLAGS= DESTDIR=/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/image PREFIX=/usr CONFDIR=/etc/vdr VIDEODIR=/var/lib/vdr/video PLUGINLIBDIR=/usr/lib/vdr/plugins LOCDIR=/usr/share/locale install
        Plugin hello:
        make[1]: Entering directory `/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/vdr-1.7.10/PLUGINS/src/hello'
        make[1]: Leaving directory `/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/vdr-1.7.10/PLUGINS/src/hello'
        make[1]: Entering directory `/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/vdr-1.7.10/PLUGINS/src/hello'
        arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"hello"' -I../../../include hello.c
        arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -shared hello.o -o libvdr-hello.so -L/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=gnu
        /oe/tangstrom-dev/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.4.2/../../../../arm-angstrom-linux-gnueabi/bin/ld: hello.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
        hello.o: could not read symbols: Bad value
        collect2: ld returned 1 exit status
        make[1]: *** [libvdr-hello.so] Error 1
        make[1]: Leaving directory `/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/vdr-1.7.10/PLUGINS/src/hello'
        
        [… same for all other plugins]

The thing that puzzles me is, that in the plugin’s Makefile [4] `-fPIC`
is specified

        CXX      ?= g++
        CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses
        LIBS     ?= ${LDFLAGS}

but in the above command it is not included.

        arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"hello"' -I../../../include hello.c

Looking at `run.do_install.28829` I cannot see find the `-fPIC` in
there. So my question is, why is it not included. Is it because of »?=«?
How do I get it included?

        $ grep -i cxxflags run.do_install.28829
        export TARGET_CXXFLAGS="-isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive"
        export CXXFLAGS="-isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden"
        export SDK_CXXFLAGS="-isystem/oe/tangstrom-dev/staging/i686-linux/usr/include -isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive"
        export BUILD_CXXFLAGS="-isystem/oe/tangstrom-dev/staging/i686-linux/usr/include -O2 -g -fpermissive"

`conf/bitbake.conf` [5] seems to be the place where those environment
variables are set.

        $ grep -i cxxflags conf/bitbake.conf 
        export BUILD_CXXFLAGS = "${BUILD_CFLAGS} -fpermissive"
        export CXXFLAGS = "${TARGET_CXXFLAGS}"
        export TARGET_CXXFLAGS = "${TARGET_CFLAGS} -fpermissive"
        export SDK_CXXFLAGS = "${SDK_CFLAGS} -fpermissive"

So to summarize it looks like `CXXFLAGS` gets set to `TARGET_CXXFLAGS` –
which just gets exported afterward? – by BitBake. Because in
`oe_runmake` `make` is run with `-e` these variables take precedence
over the one in the Makefile of the program which are additionally just
declared with »?=«. Is this correct?

How do I get this fixed? Do I need to use `TARGET_CXXFLAGS_append +=` or
`--extra-cxxflags` as found by `git grep "target_cxxflags"`?


Thanks a lot,

Paul


[1] http://www.angstrom-distribution.org/building-angstrom
[2] http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-January/016153.html
[3] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/vdr/vdr_1.7.10.bb
[4] http://git.gekrumbel.de/vdr.git?p=vdr.git;a=blob;f=PLUGINS/src/hello/Makefile;h=ea5b8063be9768b5097eedfc0bf210128e5d4043;hb=HEAD
[5] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/conf/bitbake.conf

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [vdr] TARGET_CXXFLAGS do not include CXX_FLAGS from Makefile (was: vdr: questions regarding cplusplus.patch)

[Khem Raj]

On (12/01/10 12:36), Paul Menzel wrote:
> Dear OE hackers,
> 
> 
> Am Montag, den 11.01.2010, 23:42 +0100 schrieb Paul Menzel:
> 
> […]
> 
> > Putting
> > 
> >         PREFERRED_VERSION_binutils               = "2.20"
> >         PREFERRED_VERSION_binutils-cross         = "2.20"
> >         PREFERRED_VERSION_binutils-cross-sdk     = "2.20"
> >         
> >         PREFERRED_VERSION_gcc                    = "4.4.2"
> >         PREFERRED_VERSION_gcc-cross              = "4.4.2"
> >         PREFERRED_VERSION_gcc-cross-sdk          = "4.4.2"
> >         PREFERRED_VERSION_gcc-cross-initial      = "4.4.2"
> >         PREFERRED_VERSION_gcc-cross-intermediate = "4.4.2"
> > 
> > in my `local.conf` and running `bitbake vdr` gave me an error in
> > `do_compile` for `libcap_1.10.bb`.
> > 
> >         arm-angstrom-linux-gnueabi-ld -soname libcap.so.1 -x -shared -o libcap.so.1.10 cap_alloc.o cap_proc.o cap_extint.o cap_flag.o cap_text.o cap_sys.o
> >         arm-angstrom-linux-gnueabi-ld: cap_text.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> 
> I opened a new thread for this [2].
> 
> Anyways compiling the plugins for VDR in `do_install` [3]
> 
>         do_install () {
>               oe_runmake 'DESTDIR=${D}' \
>                          'PREFIX=${prefix}' \
>                          'CONFDIR=${sysconfdir}/vdr' \
>                          'VIDEODIR=/var/lib/vdr/video' \
>                          'PLUGINLIBDIR=${PLUGINDIR}' \
>                          'LOCDIR=${datadir}/locale' \
>                          install
>         }
> 
> I also get the same error which I did not get before with GCC 4.1.1.

Older versions of binutils/ld can not detect MOVT/MOVW relocations which
are absolute and cant be used in PIC code.
hence even if the error was there it remained latent. 

> 
>         /oe/tangstrom-dev/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.4.2/../../../../arm-angstrom-linux-gnueabi/bin/ld: hello.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
>         hello.o: could not read symbols: Bad value
>         collect2: ld returned 1 exit status
>         make[1]: *** [libvdr-hello.so] Error 1
>         make[1]: Leaving directory `/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/vdr-1.7.10/PLUGINS/src/hello'
>         
>         [… same for all other plugins]
> 
> The thing that puzzles me is, that in the plugin’s Makefile [4] `-fPIC`
> is specified
> 
>         CXX      ?= g++
>         CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses
>         LIBS     ?= ${LDFLAGS}
> 
> but in the above command it is not included.

These are conditional so may be you already have defined CXXFLAGS in
your environment infact bitbake will do it for you.

> 
>         arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"hello"' -I../../../include hello.c
> 
> Looking at `run.do_install.28829` I cannot see find the `-fPIC` in
> there. So my question is, why is it not included. Is it because of »?=«?
> How do I get it included?

you could do CXXFLAGS_append = ... in the recipe.

Re: [vdr] TARGET_CXXFLAGS do not include CXX_FLAGS from Makefile

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 4324 bytes --]

Am Mittwoch, den 13.01.2010, 02:27 -0800 schrieb Khem Raj:
> On (12/01/10 12:36), Paul Menzel wrote:
> > Am Montag, den 11.01.2010, 23:42 +0100 schrieb Paul Menzel:
> > 
> > […]
> > 
> > > Putting
> > > 
> > >         PREFERRED_VERSION_binutils               = "2.20"
> > >         PREFERRED_VERSION_binutils-cross         = "2.20"
> > >         PREFERRED_VERSION_binutils-cross-sdk     = "2.20"
> > >         
> > >         PREFERRED_VERSION_gcc                    = "4.4.2"
> > >         PREFERRED_VERSION_gcc-cross              = "4.4.2"
> > >         PREFERRED_VERSION_gcc-cross-sdk          = "4.4.2"
> > >         PREFERRED_VERSION_gcc-cross-initial      = "4.4.2"
> > >         PREFERRED_VERSION_gcc-cross-intermediate = "4.4.2"
> > > 
> > > in my `local.conf` and running `bitbake vdr` gave me an error in
> > > `do_compile` for `libcap_1.10.bb`.
> > > 
> > >         arm-angstrom-linux-gnueabi-ld -soname libcap.so.1 -x -shared -o libcap.so.1.10 cap_alloc.o cap_proc.o cap_extint.o cap_flag.o cap_text.o cap_sys.o
> > >         arm-angstrom-linux-gnueabi-ld: cap_text.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> > 
> > I opened a new thread for this [2].
> > 
> > Anyways compiling the plugins for VDR in `do_install` [3]
> > 
> >         do_install () {
> >               oe_runmake 'DESTDIR=${D}' \
> >                          'PREFIX=${prefix}' \
> >                          'CONFDIR=${sysconfdir}/vdr' \
> >                          'VIDEODIR=/var/lib/vdr/video' \
> >                          'PLUGINLIBDIR=${PLUGINDIR}' \
> >                          'LOCDIR=${datadir}/locale' \
> >                          install
> >         }
> > 
> > I also get the same error which I did not get before with GCC 4.1.1.
> 
> Older versions of binutils/ld can not detect MOVT/MOVW relocations which
> are absolute and cant be used in PIC code.
> hence even if the error was there it remained latent.

Sorry for the noob question. In earlier versions would the resulting
binaries/packages have been buggy?

> > 
> >         /oe/tangstrom-dev/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.4.2/../../../../arm-angstrom-linux-gnueabi/bin/ld: hello.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> >         hello.o: could not read symbols: Bad value
> >         collect2: ld returned 1 exit status
> >         make[1]: *** [libvdr-hello.so] Error 1
> >         make[1]: Leaving directory `/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/vdr-1.7.10/PLUGINS/src/hello'
> >         
> >         [… same for all other plugins]
> > 
> > The thing that puzzles me is, that in the plugin’s Makefile [4] `-fPIC`
> > is specified
> > 
> >         CXX      ?= g++
> >         CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses
> >         LIBS     ?= ${LDFLAGS}
> > 
> > but in the above command it is not included.
> 
> These are conditional so may be you already have defined CXXFLAGS in
> your environment infact bitbake will do it for you.

I did not define any CXXFLAGS. It looks like BitBake is setting them and
not respecting those in the Makefile.

> >         arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"hello"' -I../../../include hello.c
> > 
> > Looking at `run.do_install.28829` I cannot see find the `-fPIC` in
> > there. So my question is, why is it not included. Is it because of »?=«?
> > How do I get it included?
> 
> you could do CXXFLAGS_append = ... in the recipe.

Is that the recommended behavior? Is `oe_runmake` maybe not the correct
command to use? As written above, it is very strange for me, that
BitBake does not respect the flags in the Makefile automatically,
because I think it is common in upstream Makefiles to use »?=«, is not
is?

Or is that the default behavior running `oe_runmake` in `do_install`?


Thanks,

Paul

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [vdr] TARGET_CXXFLAGS do not include CXX_FLAGS from Makefile

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-01-10 11:44, Paul Menzel wrote:

> I did not define any CXXFLAGS. It looks like BitBake is setting them and
> not respecting those in the Makefile.

In 99.99% of the cases OE knows a while lot better which flags to use :)
If upstream has the need for a specific flag, they should append it to
CXXFLAGS in the makefile, not redefine CXXFLAGS.

/me hugs make -e

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLTabKMkyGM64RGpERAon4AJ9rWJTYCUn4qY2SeFb4e1epmS0BNgCgjAIe
c9o7aF5uxPwToxWmksTi9ng=
=Y6/z
-----END PGP SIGNATURE-----

Re: [vdr] TARGET_CXXFLAGS do not include CXX_FLAGS from Makefile

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Am Mittwoch, den 13.01.2010, 11:56 +0100 schrieb Koen Kooi:
> On 13-01-10 11:44, Paul Menzel wrote:
> 
> > I did not define any CXXFLAGS. It looks like BitBake is setting them
> and
> > not respecting those in the Makefile.
> 
> In 99.99% of the cases OE knows a while lot better which flags to
> use :)
> If upstream has the need for a specific flag, they should append it to
> CXXFLAGS in the makefile, not redefine CXXFLAGS.

Thanks for your answer. Now I know, what to tell.


Thanks,

Paul

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [vdr] TARGET_CXXFLAGS do not include CXX_FLAGS from Makefile

[Khem Raj]

On (13/01/10 11:44), Paul Menzel wrote:
> > > I also get the same error which I did not get before with GCC 4.1.1.
> > 
> > Older versions of binutils/ld can not detect MOVT/MOVW relocations which
> > are absolute and cant be used in PIC code.
> > hence even if the error was there it remained latent.
> 
> Sorry for the noob question. In earlier versions would the resulting
> binaries/packages have been buggy?

Could be

> 
> > > 
> > >         /oe/tangstrom-dev/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.4.2/../../../../arm-angstrom-linux-gnueabi/bin/ld: hello.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> > >         hello.o: could not read symbols: Bad value
> > >         collect2: ld returned 1 exit status
> > >         make[1]: *** [libvdr-hello.so] Error 1
> > >         make[1]: Leaving directory `/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/vdr-1.7.10/PLUGINS/src/hello'
> > >         
> > >         [… same for all other plugins]
> > > 
> > > The thing that puzzles me is, that in the plugin’s Makefile [4] `-fPIC`
> > > is specified
> > > 
> > >         CXX      ?= g++
> > >         CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses
> > >         LIBS     ?= ${LDFLAGS}
> > > 
> > > but in the above command it is not included.
> > 
> > These are conditional so may be you already have defined CXXFLAGS in
> > your environment infact bitbake will do it for you.
> 
> I did not define any CXXFLAGS. It looks like BitBake is setting them and
> not respecting those in the Makefile.

could be bitbake set it up.

> 
> > >         arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -isystem/oe/tangstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"hello"' -I../../../include hello.c
> > > 
> > > Looking at `run.do_install.28829` I cannot see find the `-fPIC` in
> > > there. So my question is, why is it not included. Is it because of »?=«?
> > > How do I get it included?
> > 
> > you could do CXXFLAGS_append = ... in the recipe.
> 
> Is that the recommended behavior? 

yes.

Is `oe_runmake` maybe not the correct
> command to use? As written above, it is very strange for me, that
> BitBake does not respect the flags in the Makefile automatically,
> because I think it is common in upstream Makefiles to use »?=«, is not
> is?
> 

Well bitbake provides/constructs and environment where cross builds can
happen and it has to do so much more to cater to the Makefiles sometimes
which do not understand cross build. 

> Or is that the default behavior running `oe_runmake` in `do_install`?
> 
> 
> Thanks,
> 
> Paul



> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [vdr] TARGET_CXXFLAGS do not include CXX_FLAGS from Makefile

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

Am Mittwoch, den 13.01.2010, 03:02 -0800 schrieb Khem Raj:

[…]

> > > > Looking at `run.do_install.28829` I cannot see find the `-fPIC` in
> > > > there. So my question is, why is it not included. Is it because of »?=«?
> > > > How do I get it included?
> > > 
> > > you could do CXXFLAGS_append = ... in the recipe.
> > 
> > Is that the recommended behavior? 
> 
> yes.

I just tried your suggestion. The problem is, that `-fPIC` is just need
during `do_install` since strangely that is when the plugins get
compiled.

        do_install () {
              oe_runmake 'DESTDIR=${D}' \
                         'PREFIX=${prefix}' \
                         'CONFDIR=${sysconfdir}/vdr' \
                         'VIDEODIR=/var/lib/vdr/video' \
                         'PLUGINLIBDIR=${PLUGINDIR}' \
                         'LOCDIR=${datadir}/locale' \
                         install
        }

Using `CXXFLAGS_append = " -fPIC` in `do_install` gives me this error.

        + do_install
        + CXXFLAGS_append += ' -fPIC'
        /srv/filme/oe/tangstrom-dev/work/armv7a-angstrom-linux-gnueabi/vdr-1.7.10-r3/temp/run.do_install.17984: line 540: CXXFLAGS_append: command not found
        ERROR: function do_install failed

Adding `-fPIC` to the global `CXXFLAGS` is not desired, since the main
binary should not be compiled with this flag.

What solution is recommended in such a situation besides patching the
Makefiles? Add 'CXXFLAGS+=${CXXFLAGS}' to `oe_runmake`?

[…]


Thanks,

Paul

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]