stlport-devel

[Stlport-devel] Git HEAD is not building.

[Wojciech M. <Woj...@ar...>]

Hi,

As for today, I am having problems building git trunk version of STLport:

c++ -pthread -fexceptions  -fPIC -O2 -fuse-cxa-atexit  -fvisibility=hidden
-D_GNU_SOURCE -I../stlport  -c -o obj/gcc/so/dll_main.o dll_main.cpp
In file included from ../stlport/utility:27:0,
                 from dll_main.cpp:40:
../stlport/type_traits:889:22: error: 'declval' was not declared in this
scope
../stlport/type_traits:889:33: error: expected primary-expression before '>'
token
../stlport/type_traits:889:35: error: expected primary-expression before ')'
token
../stlport/type_traits:889:39: error: 'declval' was not declared in this
scope
../stlport/type_traits:889:50: error: expected primary-expression before '>'
token
../stlport/type_traits:889:52: error: expected primary-expression before ')'
token
../stlport/type_traits:889:62: error: ISO C++ forbids declaration of
'decltype' with no type
../stlport/type_traits:889:62: error: ISO C++ forbids in-class
initialization of non-const static member 'decltype'
../stlport/type_traits:889:62: error: template declaration of 'int
stlp_std::tr1::detail::decltype'
../stlport/type_traits:942:77: error: ISO C++ forbids declaration of
'decltype' with no type
../stlport/type_traits:942:77: error: ISO C++ forbids in-class
initialization of non-const static member 'decltype'
../stlport/type_traits:942:77: error: template declaration of 'int
stlp_std::tr1::detail::decltype'
make[1]: *** [obj/gcc/so/dll_main.o] Error 1
make[1]: Leaving directory `/work/git/stlport/src'
make: *** [release-shared] Error 2

It happens both with gcc 4.2.1 and 4.5.2. 

Commenting invasive lines removes error messages and builds STLport.

Any thoughts what it might be?

Thanks,
Wojciech

Re: [Stlport-devel] Git HEAD is not building.

[Petr O. <pt...@vo...>]

On Tue, 1 Mar 2011 14:17:56 -0000
"Wojciech Meyer" <Woj...@ar...> wrote:

> Hi,
> 
> As for today, I am having problems building git trunk version of STLport:
> 
> c++ -pthread -fexceptions  -fPIC -O2 -fuse-cxa-atexit  -fvisibility=hidden
> -D_GNU_SOURCE -I../stlport  -c -o obj/gcc/so/dll_main.o dll_main.cpp
> In file included from ../stlport/utility:27:0,
>                  from dll_main.cpp:40:
> ../stlport/type_traits:889:22: error: 'declval' was not declared in this
> scope

Pass option -std=gnu++0x to C++ compiler. You may do it via

./configure --with-extra-cxxflags=-std=gnu++0x

or directly edit Makefiles/gmake/config.mak, add line

EXTRA_CXXFLAGS = -std=gnu++0x

Explanation: mainstream is on road to C++ 0x standard, so in mainstream
appears 0x constructions. No time now to write workaround for 1998/2003
standard. May be workarounds will be added later.

> ../stlport/type_traits:889:33: error: expected primary-expression before '>'
> token
> ../stlport/type_traits:889:35: error: expected primary-expression before ')'
> token
> ../stlport/type_traits:889:39: error: 'declval' was not declared in this
> scope
> ../stlport/type_traits:889:50: error: expected primary-expression before '>'
> token
> ../stlport/type_traits:889:52: error: expected primary-expression before ')'
> token
> ../stlport/type_traits:889:62: error: ISO C++ forbids declaration of
> 'decltype' with no type
> ../stlport/type_traits:889:62: error: ISO C++ forbids in-class
> initialization of non-const static member 'decltype'
> ../stlport/type_traits:889:62: error: template declaration of 'int
> stlp_std::tr1::detail::decltype'
> ../stlport/type_traits:942:77: error: ISO C++ forbids declaration of
> 'decltype' with no type
> ../stlport/type_traits:942:77: error: ISO C++ forbids in-class
> initialization of non-const static member 'decltype'
> ../stlport/type_traits:942:77: error: template declaration of 'int
> stlp_std::tr1::detail::decltype'
> make[1]: *** [obj/gcc/so/dll_main.o] Error 1
> make[1]: Leaving directory `/work/git/stlport/src'
> make: *** [release-shared] Error 2
> 
> It happens both with gcc 4.2.1 and 4.5.2. 
> 
> Commenting invasive lines removes error messages and builds STLport.
> 
> Any thoughts what it might be?
> 
> Thanks,
> Wojciech

Re: [Stlport-devel] Git HEAD is not building.

[Wojciech M. <Woj...@ar...>]

Hi Petr,

> Pass option -std=gnu++0x to C++ compiler. You may do it via
> ./configure --with-extra-cxxflags=-std=gnu++0x
> or directly edit Makefiles/gmake/config.mak, add line
> EXTRA_CXXFLAGS = -std=gnu++0x

Thanks, indeed it fixes the problem.

> Explanation: mainstream is on road to C++ 0x standard, so in mainstream
> appears 0x constructions. No time now to write workaround for 1998/2003
> standard. May be workarounds will be added later.

Thanks, this does sound reasonable.

That does mean, 5.2 line is the last one before some of the features of
C++Ox
compiler will be required to build STLport?

Would you be happy to accept a patch up-stream to stable 5.2 line or I'd
need
really to stick with the trunk?

Thanks.
Wojciech

Re: [Stlport-devel] Git HEAD is not building.

[Petr O. <pt...@vo...>]

On Thu, 3 Mar 2011 10:05:05 -0000
"Wojciech Meyer" <Wojciech.Meyer@...> wrote:

> ...
> 
> That does mean, 5.2 line is the last one before some of the features of
> C++Ox compiler will be required to build STLport?

May be. But there are another possible ways:

  - after code clean and implementations of C++0x draft, will be added
    workarounds for relativly modern, but still not C++0x (i.e. at least
    ISO/IEC 14882/2003);

  - 5.2 line may live too

> 
> Would you be happy to accept a patch up-stream to stable 5.2 line or I'd
> need really to stick with the trunk?

I will consider any reasonable patch. Preferable way---'git format-patch'
against proper branch. If you suggest resolving bug in C/C++ code,
then pay attention to unit test, that demonstrate bug's presence (before) and
resolving (after) [unit test frameworks are bit different in 5.2 in mainstream].

Backports of mainstream to 5.2 in general not planned, except some bugs
that present in both branches and has similar solutions.

--

Bests,

  - Petr

Re: [Stlport-devel] [PATCH] ARM toolchain support for STLport-5.2 (was: Git HEAD is not building.)

[Wojciech M. <Woj...@ar...>]

Hi Petr,

> > Would you be happy to accept a patch up-stream to stable 5.2 line or I'd
> > need really to stick with the trunk?

> I will consider any reasonable patch. Preferable way---'git format-patch'
> against proper branch. If you suggest resolving bug in C/C++ code,
> then pay attention to unit test, that demonstrate bug's presence (before)
and
> resolving (after) [unit test frameworks are bit different in 5.2 in
mainstream].

Since ARM compiler has not been supported by STLport before, and we
would like to have this support up-stream, we prepared a porting patch
for armcc compiler. We've decided to stick with 5.2 STLport line, as it
seems to be most suitable for this purpose. Please find the patch
attached that implements cross compilation of STLport using ARM
toolchain. The patch has been tested in our environment and passes unit
tests.

The patch is against current `STLport-5.2' git branch.

Thanks, 
Wojciech

Re: [Stlport-devel] [PATCH] ARM toolchain support for STLport-5.2 (was: Git HEAD is not building.)

[Wojciech M. <Woj...@ar...>]

> Hi Petr,

> > > Would you be happy to accept a patch up-stream to stable 5.2 line or
I'd
> > > need really to stick with the trunk?

> > I will consider any reasonable patch. Preferable way---'git
format-patch'
> > against proper branch. If you suggest resolving bug in C/C++ code,
> > then pay attention to unit test, that demonstrate bug's presence
(before)
> and
> > resolving (after) [unit test frameworks are bit different in 5.2 in
> mainstream].

> Since ARM compiler has not been supported by STLport before, and we
> would like to have this support up-stream, we prepared a porting patch
> for armcc compiler. We've decided to stick with 5.2 STLport line, as it
> seems to be most suitable for this purpose. Please find the patch
> attached that implements cross compilation of STLport using ARM
> toolchain. The patch has been tested in our environment and passes unit
> tests.

> The patch is against current `STLport-5.2' git branch.

> Thanks, 
> Wojciech

Hi Petr,

I've just noticed that the header configuration file _armcc.h is missing in
the 
former patch. Apologises for that, and please see the patch including this
file.

Thanks.
Wojciech

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Petr O. <pt...@vo...>]

Hi Wojciech,

Thanks for patch.

On Fri, 4 Mar 2011 13:35:52 -0000
"Wojciech Meyer" <Woj...@ar...> wrote:

> 
> > Since ARM compiler has not been supported by STLport before, and we
> > would like to have this support up-stream, we prepared a porting patch
> > for armcc compiler. We've decided to stick with 5.2 STLport line, as it
> > seems to be most suitable for this purpose. Please find the patch
> > attached that implements cross compilation of STLport using ARM
> > toolchain. The patch has been tested in our environment and passes unit
> > tests.
> 

I have question about this lines (build/test/unit/armcc.mak):

+ifeq ($(OSNAME), linux)
+release-shared: LDFLAGS += -L${STLPORT_DIR}/build/lib/${OUTPUT_DIR_STLDBG}/libstlportstlg.a
+dbg-shared:    LDFLAGS += -L${STLPORT_DIR}/build/lib/${OUTPUT_DIR_STLDBG}/libstlportstlg.a
+stldbg-shared: LDFLAGS += -L${STLPORT_DIR}/build/lib/${OUTPUT_DIR_STLDBG}/libstlportstlg.a

 - -L is a path to, not archive itself, isn't it?

 - do you understand problems of using C++ code in static libraries?
   If you link with static STLport lib, the behaviour of program
   will be undefined if you write something like

#include <iostream>
#include <iomanip>

using std;

struct f
{
  f();
};

f::f()
{
  cerr << __FILE__ << ':' << __LINE__ << endl;
}

static f obj;

int main()
{
  return 0;
}


Why you comment this (build/test/unit/armcc.mak):

+#-include ${SRCROOT}/Makefiles/gmake/config.mak

?


I don't see stl/config/_armgcc.h, but see

+#  elif defined ( __ARMCC_VERSION) && defined(_GNU_SOURCE)
+#    include <stl/config/_armgcc.h>
+#  elif defined ( __ARMCC_VERSION) 
+#    include <stl/config/_armcc.h>


Patch should contain 'commit notes', i.e. description of this commit
(see 'git log' under STLport-5.2 branch, for example).

--

Bests,

  - Petr

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Wojciech M. <Woj...@ar...>]

Hi Petr,

Thanks for reviewing and considering our patch for armcc support!

> I have question about this lines (build/test/unit/armcc.mak):

> +ifeq ($(OSNAME), linux)
> +release-shared: LDFLAGS +=
-L${STLPORT_DIR}/build/lib/${OUTPUT_DIR_STLDBG}/libstlportstlg.a
> +dbg-shared:    LDFLAGS +=
-L${STLPORT_DIR}/build/lib/${OUTPUT_DIR_STLDBG}/libstlportstlg.a
> +stldbg-shared: LDFLAGS +=
-L${STLPORT_DIR}/build/lib/${OUTPUT_DIR_STLDBG}/libstlportstlg.a

>  - -L is a path to, not archive itself, isn't it?

In GNU toolchain - yes, but in ARM toolchain this option specifies
command-line options to pass to the linker when a link step is being
performed after compilation. So the library itself is passed as an
argument.

>  - do you understand problems of using C++ code in static libraries?
>    If you link with static STLport lib, the behaviour of program
>    will be undefined if you write something like

> #include <iostream>
> #include <iomanip>

> using std;

> struct f
> {
>   f();
> };

> f::f()
> {
>   cerr << __FILE__ << ':' << __LINE__ << endl;
> }

> static f obj;

> int main()
> {
>   return 0;
> }

In fact, I know that the static constructors have a bit complicated
semantics in C++, and I understand that the dynamic libraries are being
loaded lazily, so there is additional dependency, and that we don't have
control over the order of static constructors begin called in a scope of
an image. The reason why we favor linking statically is that how most
often armcc is used. Armcc is heavily used in embedded world where there
is no support for dynamic linking, and sometimes even no file system. I
think linking as a static library is perfectly safe it developers are
aware about possible quirks. We might want later add a dynamic library
support as well if you have no objections to it.

> Why you comment this (build/test/unit/armcc.mak):

> +#-include ${SRCROOT}/Makefiles/gmake/config.mak

> ?

> I don't see stl/config/_armgcc.h, but see

> +#  elif defined ( __ARMCC_VERSION) && defined(_GNU_SOURCE)
> +#    include <stl/config/_armgcc.h>
> +#  elif defined ( __ARMCC_VERSION) 
> +#    include <stl/config/_armcc.h>


> Patch should contain 'commit notes', i.e. description of this commit
> (see 'git log' under STLport-5.2 branch, for example).

Let me work on these remaining problems, I can't do it right now, but
promise to get back to this ASAP when I will be able (which will be
someday in the middle of this week or even tomorrow). I will fix the
remaining problems and send you corrected patch.

Thanks,
Wojciech

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Wojciech M. <Woj...@ar...>]

Hi Petr,

> Why you comment this (build/test/unit/armcc.mak):

> +#-include ${SRCROOT}/Makefiles/gmake/config.mak

> ?

This has been fixed!

> I don't see stl/config/_armgcc.h, but see

> +#  elif defined ( __ARMCC_VERSION) && defined(_GNU_SOURCE)
> +#    include <stl/config/_armgcc.h>
> +#  elif defined ( __ARMCC_VERSION) 
> +#    include <stl/config/_armcc.h>

This as well.

> Patch should contain 'commit notes', i.e. description of this commit
> (see 'git log' under STLport-5.2 branch, for example).

Please see the corrected commit notes and let me know if you are happy with
it.

Thanks!
Wojciech

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Petr O. <pt...@vo...>]

On Tue, 8 Mar 2011 14:10:09 -0000
"Wojciech Meyer" <Woj...@ar...> wrote:

> ...
> Please see the corrected commit notes and let me know if you are happy with
> it.
> 

In STLport-5.2 branch, 773d1982. I made little change only in commit notes.
Thanks for you contribution!

--

Bests,

  - Petr

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Wojciech M. <Woj...@ar...>]

> In STLport-5.2 branch, 773d1982. I made little change only in commit
notes.
> Thanks for you contribution!

Thanks for being able to contribute to STLport!

I pulled latest changes and noticed that one armcc.mak build file is
missing (probably got missed somewhere when I was preparing the patch),
sorry about this. Please apply the attached patch to fix this single
problem. After this, I was able to build STLport and run the unit tests
with the ARM toolchain. Apologises for any inconvenience.

Thanks,
Wojciech

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Petr O. <pt...@vo...>]

On Wed, 9 Mar 2011 10:20:22 -0000
"Wojciech Meyer" <Woj...@ar...> wrote:

> 
> ...
> I pulled latest changes and noticed that one armcc.mak build file is
> missing (probably got missed somewhere when I was preparing the patch),
> sorry about this. Please apply the attached patch to fix this single
> problem. After this, I was able to build STLport and run the unit tests
> with the ARM toolchain. Apologises for any inconvenience.
> 

Done.

--

Bests,

   - Petr

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Wojciech M. <Woj...@ar...>]

> Done.

Thanks. Now it works.

On this occasion I would like to ask, do you have any concrete plans for
5.2.x
line? You've mentioned before that it might be still be alive.

Thanks,
Wojciech

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Petr O. <pt...@vo...>]

On Wed, 9 Mar 2011 11:26:38 -0000
"Wojciech Meyer" <Woj...@ar...> wrote:

> ...
> On this occasion I would like to ask, do you have any concrete plans for
> 5.2.x line? You've mentioned before that it might be still be alive.
> 

5.2 line open for patches/platform support within standard 2003.

I don't expect that as C++0x constructions will appear here as significant
architecture changes.

--

Bests,

  - Petr

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Nigel S. <nst...@nv...>]

>> On this occasion I would like to ask, do you have any concrete plans for
>> 5.2.x line? You've mentioned before that it might be still be alive.
>
> 5.2 line open for patches/platform support within standard 2003.

Wojciech,

I expect 5.2 to be around for a while, one way or another.
In a multi-platform context, making the leap to C++0x
is going to be a lot of (as yet unscheduled) work.

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------