Re: 4.3.x linux packages and collada support

2014-09-30 Thread Zolnai Tamás
2014-09-27 20:57 GMT+02:00 Michael Stahl mst...@redhat.com:

 On 27/09/14 16:05, Zolnai Tamás wrote:
  2014-09-27 15:23 GMT+02:00 Miklos Vajna vmik...@collabora.co.uk
  mailto:vmik...@collabora.co.uk:
 
  On Sat, Sep 27, 2014 at 08:26:38AM +0200, Zolnai Tamás
  zolnaitamas2...@gmail.com mailto:zolnaitamas2...@gmail.com
 wrote:
   So the only question is:
   Is it possible to replace the 4.3.1 and 4.3.2 linux packages with
 new ones
   which are compiled with newer compilers? (expecting this is the
 problem)
   To fix the bug mentioned above.
 
  Isn't it possible to stick to boost::shared_ptr on -4-3, given that's
  what other code does?
 
 
  It's the collada2gltf code which uses std::shared_ptr at many places so
  it would be much work to replace all of them with boost::shared_ptr, but
  actually can be done if necessary. I just thought packages are created
  with newer compilers, since they generate more better output (in theory).
  Other thing is that I need to know whether this is the problem indeed.
  So can I know what compilers are used for packages? Are they support
  std::shared_ptr?

 for LO 4.3 and earlier releases the RHEL5 gcc is used, i don't remember
 if it is gcc 4.1 or 4.4; we're only switching to a C++11 compiler for LO
 4.4.

 actually most users will use the distro provided LO packages anyway and
 those don't suffer from our ancient upstream RHEL5 baseline.

 anyway, std::shared_ptr and boost::shared_ptr should be mostly the same,
 so find ... | xargs sed -i ... should be able to fix things up quite
 quickly to get a patch for the 4.3 branch.


Hi,

So I replaced all C++11 code from collada2gltf and it compiles for me with
--std=c++03 flag and the feature works as expected. Here is the patch for
4.3 branch:
https://gerrit.libreoffice.org/#/c/11706/

It would be helpful to test whether it compiles and works with the old
compilers used for packaging.


Thanks,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-29 Thread Stephan Bergmann

On 09/28/2014 11:46 AM, Zolnai Tamás wrote:

I tried it an it came out there are other C++11 stuff in the code. I
tried to replace them, but the compiler does not help me with finding
C++11 code. When I compile with --std=c++03 flag, compiler just write out:
error: #error This file requires compiler and library support for the
ISO C++ 2011 standard. This support is currently experimental, and must
be enabled with the -std=c++11 or -std=gnu++11 compiler options.
Is there any option to avoid this general error and force the compiler
to try the older standard.


That #error message smells like some code includes a standard header 
that is suitable for C++11 only and includes libstdc++'s 
bits/c++0x_warning.h which contains



#if __cplusplus  201103L
#error This file requires compiler and library support for the \
ISO C++ 2011 standard. This support is currently experimental, and must be \
enabled with the -std=c++11 or -std=gnu++11 compiler options.
#endif


You need to track down the include stack (which is typically spit out by 
GCC before showing the #error diagnostic, no?) to see what problematic 
standard header is being included where.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-29 Thread Michael Meeks

On Sun, 2014-09-28 at 13:48 +0200, Zolnai Tamás wrote:
 That's the point where we should have realized that collada2gltf uses
 C++11 and so should not be part of 4.3, but it seems in this case our
 division of labor lead to information loss.

Fair enough - lets see if we can't work out some solution with the
collada2gltf authors to clean this up =)

ATB,

Michael.

-- 
 michael.me...@collabora.com  , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support (also affects master with gcc 4.6)

2014-09-29 Thread Jan-Marek Glogowski
Hi,

just want to add, that the Ubuntu 12.04 master TB build (gcc 4.6) just
builds with --disable-collada. I just checked again and fixed the
build errors locally:


1. It doesn't find unordered_map for whatever reason, but calls g++ with
-std=gnu++0x

I get:

workdir/UnpackedTarball/collada2gltf/GLTF/GLTFProfile.h:33:9: error:
‘unordered_map’ in namespace ‘std’ does not name a type

But workdir/UnpackedTarball/collada2gltf/GLTF/GLTF.h has:

#if (defined(WIN32) || defined(_LIBCPP_VERSION) || __cplusplus  199711L)
#include memory
#include unordered_map
#else
#include tr1/memory
#include tr1/unordered_map
#endif

So either the #if preprozessor macro is wrong or it's a g++ / stdlib
error, as g++ finds unordered_map, if I manually select unordered_map
instead of tr1/unordered_map.

Same applies to
workdir/UnpackedTarball/collada2gltf/GLTF/GLTFExtraDataHandler.h


2. It tries to use the std::tr1 namespace

This is disguised version of the first error. This is fixed by running

# find workdir/UnpackedTarball/collada2gltf -type f -print0 | xargs -0
sed -i -e '/^using namespace std::tr1;$/d'

There are a lot of in the code. Not sure why it's not the same macro
then in the headers:

#if __cplusplus = 199711L
using namespace std::tr1;
#endif

Otherwise I see a lot of

collada2gltf/COLLADA2GLTFWriter.cpp:133:84: error: reference to
‘shared_ptr’ is ambiguous
/usr/include/c++/4.6/bits/shared_ptr_base.h:264:11: error: candidates
are: templateclass _Tp class std::shared_ptr
/usr/include/c++/4.6/tr1/shared_ptr.h:510:11: error:
templateclass _Tp class std::tr1::shared_ptr

which also breaks my build.

Anybody has an Idea, which is the corect __cplusplus version for the macro?

Regards,

Jan-Marek
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-29 Thread Christian Lohmaier
Hi Michael, *,

On Sat, Sep 27, 2014 at 8:57 PM, Michael Stahl mst...@redhat.com wrote:
 On 27/09/14 16:05, Zolnai Tamás wrote:
 2014-09-27 15:23 GMT+02:00 Miklos Vajna vmik...@collabora.co.uk
 mailto:vmik...@collabora.co.uk:
 On Sat, Sep 27, 2014 at 08:26:38AM +0200, Zolnai Tamás
 zolnaitamas2...@gmail.com mailto:zolnaitamas2...@gmail.com wrote:
  So the only question is:
  Is it possible to replace the 4.3.1 and 4.3.2 linux packages with new 
 ones
  which are compiled with newer compilers? (expecting this is the 
 problem)
  To fix the bug mentioned above.

Nope, cannot just replace already-released stuff

 [...]
 for LO 4.3 and earlier releases the RHEL5 gcc is used, i don't remember
 if it is gcc 4.1 or 4.4; we're only switching to a C++11 compiler for LO
 4.4

The release VM is CentOS 5.10 with gcc 4.4 (.7) (for both 4-2 and 4-3)
annd that indeed doesn't support std::shared_ptr (Well, by itself it
would, but configure disables C++11 support in the test whether using
C++11 causes libstdc++ 4.7.0/4.7.1 ABI breakage already)

master/future libreoffice-4-4 builds use gcc 4.8 (.2)

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support (also affects master with gcc 4.6)

2014-09-29 Thread Jan-Marek Glogowski
Just to document my findings:

Am 29.09.2014 10:41, schrieb Jan-Marek Glogowski:
 
 1. It doesn't find unordered_map for whatever reason, but calls g++ with
 -std=gnu++0x

GLTF/GLTFProfile.h uses std::unordered_map

if we define

namespace compat = std::tr;

and use it, this can be resolved.

 2. It tries to use the std::tr1 namespace

As allready mentioned in the other branch of the thread, the code uses a
lot of std::shared_ptr in headers.

A few places in the opencollada headers include memory, which gets us
std::shared_ptr, even without using it.

In the tr1 case we're also including tr1/memory, which results in the
ambiguity and no easy namespace mapping will resolve it.

Then there is COLLADABaseUtils/include/COLLADABUhash_map.h, which - I
guess - also gets me the std::shared_ptr version.

At least dropping memory.h isn't sufficient to get rid of the ambiguity.

And there seems to be no easy way, like the current macros, to decide to
using tr1, as it was mentioned in #gcc, that gcc 4.6 doesn't set the
__cplusplus macro proprely, it's always set to 1 for c++98 and c++11

Should we just drop all the TR1 support from collada2gltf at least for
LO 4.4?

Jan-Marek
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-29 Thread Zolnai Tamás
Hi Stephan,

Indeed it was a C++11 header.
Thanks for the help.

2014-09-29 9:23 GMT+02:00 Stephan Bergmann sberg...@redhat.com:

 On 09/28/2014 11:46 AM, Zolnai Tamás wrote:

 I tried it an it came out there are other C++11 stuff in the code. I
 tried to replace them, but the compiler does not help me with finding
 C++11 code. When I compile with --std=c++03 flag, compiler just write out:
 error: #error This file requires compiler and library support for the
 ISO C++ 2011 standard. This support is currently experimental, and must
 be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 Is there any option to avoid this general error and force the compiler
 to try the older standard.


 That #error message smells like some code includes a standard header that
 is suitable for C++11 only and includes libstdc++'s bits/c++0x_warning.h
 which contains

  #if __cplusplus  201103L
 #error This file requires compiler and library support for the \
 ISO C++ 2011 standard. This support is currently experimental, and must
 be \
 enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #endif


 You need to track down the include stack (which is typically spit out by
 GCC before showing the #error diagnostic, no?) to see what problematic
 standard header is being included where.

 Stephan

 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


RE: 4.3.x linux packages and collada support

2014-09-28 Thread Zolnai Tamás
-- Forwarded message --
From: Zolnai Tamás zolnaitamas2...@gmail.com
Date: 2014-09-28 10:49 GMT+02:00
Subject: Re: 4.3.x linux packages and collada support
To: Michael Meeks michael.me...@collabora.com


2014-09-27 19:25 GMT+02:00 Michael Meeks michael.me...@collabora.com:

 Hi Tamas,

 On Sat, 2014-09-27 at 16:05 +0200, Zolnai Tamás wrote:
  It's the collada2gltf code which uses std::shared_ptr at many places
  so it would be much work to replace all of them with
  boost::shared_ptr, but actually can be done if necessary.

 Interesting; we should work out what is best to do there I guess.

   I just thought packages are created with newer compilers, since they
  generate more better output (in theory).

 We compile LibreOffice on our oldest Linux base-line, which is
 something horribly old; that is because it is the only effective way to
 get backwards comaptibilioty

  Other thing is that I need to know whether this is the problem indeed.
  So can I know what compilers are used for packages? Are they support
  std::shared_ptr?

 AFAICS it is bad form to disable the feature during the release
 series
 without discussing it and/or notifying the author etc. I imagine it was
 inadvertent, and/or Cloph who normally does the compiles is on vacation
  Robinson has been standing in for a bit; I've no idea what happened
 here. I took a look at configure.ac and distro-config's on the branch
 and couldn't see what happened there either.

 What commit disabled that ?


Hi Michael,

No, not that the case. Sorry for the ambiguity. Configure script contains a
check whether std::shared_ptr exists and if not then it disables collada
support silently (because collada libraries use shared_ptr). So it was not
about the packager.
So, I guess the solution will be to kill all C++11 code from collada2gltf.


Thanks guys,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-28 Thread Zolnai Tamás
2014-09-27 20:57 GMT+02:00 Michael Stahl mst...@redhat.com:

 On 27/09/14 16:05, Zolnai Tamás wrote:
  2014-09-27 15:23 GMT+02:00 Miklos Vajna vmik...@collabora.co.uk
  mailto:vmik...@collabora.co.uk:
 
  On Sat, Sep 27, 2014 at 08:26:38AM +0200, Zolnai Tamás
  zolnaitamas2...@gmail.com mailto:zolnaitamas2...@gmail.com
 wrote:
   So the only question is:
   Is it possible to replace the 4.3.1 and 4.3.2 linux packages with
 new ones
   which are compiled with newer compilers? (expecting this is the
 problem)
   To fix the bug mentioned above.
 
  Isn't it possible to stick to boost::shared_ptr on -4-3, given that's
  what other code does?
 
 
  It's the collada2gltf code which uses std::shared_ptr at many places so
  it would be much work to replace all of them with boost::shared_ptr, but
  actually can be done if necessary. I just thought packages are created
  with newer compilers, since they generate more better output (in theory).
  Other thing is that I need to know whether this is the problem indeed.
  So can I know what compilers are used for packages? Are they support
  std::shared_ptr?

 for LO 4.3 and earlier releases the RHEL5 gcc is used, i don't remember
 if it is gcc 4.1 or 4.4; we're only switching to a C++11 compiler for LO
 4.4.

 actually most users will use the distro provided LO packages anyway and
 those don't suffer from our ancient upstream RHEL5 baseline.

 anyway, std::shared_ptr and boost::shared_ptr should be mostly the same,
 so find ... | xargs sed -i ... should be able to fix things up quite
 quickly to get a patch for the 4.3 branch.


I tried it an it came out there are other C++11 stuff in the code. I tried
to replace them, but the compiler does not help me with finding C++11 code.
When I compile with --std=c++03 flag, compiler just write out:
error: #error This file requires compiler and library support for the ISO
C++ 2011 standard. This support is currently experimental, and must be
enabled with the -std=c++11 or -std=gnu++11 compiler options.
Is there any option to avoid this general error and force the compiler to
try the older standard.

Thanks,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-28 Thread Zolnai Tamás
2014-09-27 19:25 GMT+02:00 Michael Meeks michael.me...@collabora.com:

 Hi Tamas,

 On Sat, 2014-09-27 at 16:05 +0200, Zolnai Tamás wrote:
  It's the collada2gltf code which uses std::shared_ptr at many places
  so it would be much work to replace all of them with
  boost::shared_ptr, but actually can be done if necessary.

 Interesting; we should work out what is best to do there I guess.

   I just thought packages are created with newer compilers, since they
  generate more better output (in theory).

 We compile LibreOffice on our oldest Linux base-line, which is
 something horribly old; that is because it is the only effective way to
 get backwards comaptibilioty

  Other thing is that I need to know whether this is the problem indeed.
  So can I know what compilers are used for packages? Are they support
  std::shared_ptr?

 AFAICS it is bad form to disable the feature during the release
 series
 without discussing it and/or notifying the author etc. I imagine it was
 inadvertent, and/or Cloph who normally does the compiles is on vacation
  Robinson has been standing in for a bit; I've no idea what happened
 here. I took a look at configure.ac and distro-config's on the branch
 and couldn't see what happened there either.

 What commit disabled that ?


This is the commit which adds check for std::shared_ptr:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa5fe7958d087fbd6e64b29bbf2fa6e4d9ba5ab6
Git log shows that I'm the author, but I actually did just one part of that
patch. Matus finished it adding the std::shared_ptr check (next to other
things). That's the point where we should have realized that collada2gltf
uses C++11 and so should not be part of 4.3, but it seems in this case our
division of labor lead to information loss.

Best Regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-27 Thread Miklos Vajna
On Sat, Sep 27, 2014 at 08:26:38AM +0200, Zolnai Tamás 
zolnaitamas2...@gmail.com wrote:
 So the only question is:
 Is it possible to replace the 4.3.1 and 4.3.2 linux packages with new ones
 which are compiled with newer compilers? (expecting this is the problem)
 To fix the bug mentioned above.

Isn't it possible to stick to boost::shared_ptr on -4-3, given that's
what other code does?


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-27 Thread Zolnai Tamás
2014-09-27 15:23 GMT+02:00 Miklos Vajna vmik...@collabora.co.uk:

 On Sat, Sep 27, 2014 at 08:26:38AM +0200, Zolnai Tamás 
 zolnaitamas2...@gmail.com wrote:
  So the only question is:
  Is it possible to replace the 4.3.1 and 4.3.2 linux packages with new
 ones
  which are compiled with newer compilers? (expecting this is the problem)
  To fix the bug mentioned above.

 Isn't it possible to stick to boost::shared_ptr on -4-3, given that's
 what other code does?


It's the collada2gltf code which uses std::shared_ptr at many places so it
would be much work to replace all of them with boost::shared_ptr, but
actually can be done if necessary. I just thought packages are created with
newer compilers, since they generate more better output (in theory).
Other thing is that I need to know whether this is the problem indeed. So
can I know what compilers are used for packages? Are they support
std::shared_ptr?

Thanks,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-27 Thread Michael Meeks
Hi Tamas,

On Sat, 2014-09-27 at 16:05 +0200, Zolnai Tamás wrote:
 It's the collada2gltf code which uses std::shared_ptr at many places
 so it would be much work to replace all of them with
 boost::shared_ptr, but actually can be done if necessary.

Interesting; we should work out what is best to do there I guess.

  I just thought packages are created with newer compilers, since they
 generate more better output (in theory).

We compile LibreOffice on our oldest Linux base-line, which is
something horribly old; that is because all newer releases are backwards
compatible, but no newer release makes it easy to compile for older
systems; sad but true.

 Other thing is that I need to know whether this is the problem indeed.
 So can I know what compilers are used for packages? Are they support
 std::shared_ptr?

Actually, I'm really surprised that this was turned off without any
discussion / notification to you. That's really not ideal; Cloph is away
on vacation just now - and we've had Robinson doing interim release mgmt
- but ... I'll push to the ESC agenda to investigate - it seems most
odd.

ATB,

Michael.

-- 
 michael.me...@collabora.com  , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-27 Thread Michael Meeks
Hi Tamas,

On Sat, 2014-09-27 at 16:05 +0200, Zolnai Tamás wrote:
 It's the collada2gltf code which uses std::shared_ptr at many places
 so it would be much work to replace all of them with
 boost::shared_ptr, but actually can be done if necessary.

Interesting; we should work out what is best to do there I guess.

  I just thought packages are created with newer compilers, since they
 generate more better output (in theory).

We compile LibreOffice on our oldest Linux base-line, which is
something horribly old; that is because it is the only effective way to
get backwards comaptibilioty 

 Other thing is that I need to know whether this is the problem indeed.
 So can I know what compilers are used for packages? Are they support
 std::shared_ptr?

AFAICS it is bad form to disable the feature during the release series
without discussing it and/or notifying the author etc. I imagine it was
inadvertent, and/or Cloph who normally does the compiles is on vacation
 Robinson has been standing in for a bit; I've no idea what happened
here. I took a look at configure.ac and distro-config's on the branch
and couldn't see what happened there either.

What commit disabled that ?

All the best,

Michael.

-- 
 michael.me...@collabora.com  , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: 4.3.x linux packages and collada support

2014-09-27 Thread Michael Stahl
On 27/09/14 16:05, Zolnai Tamás wrote:
 2014-09-27 15:23 GMT+02:00 Miklos Vajna vmik...@collabora.co.uk
 mailto:vmik...@collabora.co.uk:
 
 On Sat, Sep 27, 2014 at 08:26:38AM +0200, Zolnai Tamás
 zolnaitamas2...@gmail.com mailto:zolnaitamas2...@gmail.com wrote:
  So the only question is:
  Is it possible to replace the 4.3.1 and 4.3.2 linux packages with new 
 ones
  which are compiled with newer compilers? (expecting this is the problem)
  To fix the bug mentioned above.
 
 Isn't it possible to stick to boost::shared_ptr on -4-3, given that's
 what other code does?
 
 
 It's the collada2gltf code which uses std::shared_ptr at many places so
 it would be much work to replace all of them with boost::shared_ptr, but
 actually can be done if necessary. I just thought packages are created
 with newer compilers, since they generate more better output (in theory).
 Other thing is that I need to know whether this is the problem indeed.
 So can I know what compilers are used for packages? Are they support
 std::shared_ptr?

for LO 4.3 and earlier releases the RHEL5 gcc is used, i don't remember
if it is gcc 4.1 or 4.4; we're only switching to a C++11 compiler for LO
4.4.

actually most users will use the distro provided LO packages anyway and
those don't suffer from our ancient upstream RHEL5 baseline.

anyway, std::shared_ptr and boost::shared_ptr should be mostly the same,
so find ... | xargs sed -i ... should be able to fix things up quite
quickly to get a patch for the 4.3 branch.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice