Relation between gcc version and libstdc++ version

Relation between gcc version and libstdc++ version

[Anton Wöllert]

Hello list!

I was trying to build a cross-compilation toolchain for a specific
target using a newer GCC version, than the one that the binaries were
build on the target.

The C part seems to work well, but the C++ part doesn't.  It seems that
the G++ ships it's own libstdc++ include headers.  If this libstdc++ is
newer than the one one the target, I get undefined references (because
there are some newer implementation details and things like that).  Is
it possible to tell G++/GCC to use the libstdc++.so from the target and
also to use the C++ headers (like iostream) from the target?
If not, is there any reason this is hard-coded?

With clang it looks like you can specify "any" libstdc++ version you
want, although I haven't tested it yet.

Kind regards,
Anton

Re: Relation between gcc version and libstdc++ version

[Jonathan Wakely]

On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, <gcc@gcc.gnu.org> wrote:

> Hello list!
>
> I was trying to build a cross-compilation toolchain for a specific
> target using a newer GCC version, than the one that the binaries were
> build on the target.
>
> The C part seems to work well, but the C++ part doesn't.  It seems that
> the G++ ships it's own libstdc++ include headers.


Yes, because libstdc++ is part of GCC.


  If this libstdc++ is
> newer than the one one the target, I get undefined references (because
> there are some newer implementation details and things like that).


Then you're not telling the executable how find the new libstdc++.

https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths



Is
> it possible to tell G++/GCC to use the libstdc++.so from the target and
> also to use the C++ headers (like iostream) from the target?
>

It's possible, but unsupported and probably won't work.

If not, is there any reason this is hard-coded?
>

The libstdc++ headers are tightly coupled to the GCC version, so headers
from a given GCC release might not even compile with a newer or older GCC.

Re: Relation between gcc version and libstdc++ version

[Jonathan Wakely]

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

On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, <gcc@gcc.gnu.org> wrote:

> Hello list!
>
> I was trying to build a cross-compilation toolchain for a specific
> target using a newer GCC version, than the one that the binaries were
> build on the target.
>
> The C part seems to work well, but the C++ part doesn't.  It seems that
> the G++ ships it's own libstdc++ include headers.


Yes, because libstdc++ is part of GCC.


  If this libstdc++ is
> newer than the one one the target, I get undefined references (because
> there are some newer implementation details and things like that).


Then you're not telling the executable how find the new libstdc++.

https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths



Is
> it possible to tell G++/GCC to use the libstdc++.so from the target and
> also to use the C++ headers (like iostream) from the target?
>

It's possible, but unsupported and probably won't work.

If not, is there any reason this is hard-coded?
>

The libstdc++ headers are tightly coupled to the GCC version, so headers
from a given GCC release might not even compile with a newer or older GCC.

Re: Relation between gcc version and libstdc++ version

[Anton Wöllert]

Hi Jonathan,

thank you for your reply!

On Tue, 2022-08-30 at 17:09 +0100, Jonathan Wakely wrote:
> 
> 
> On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, <gcc@gcc.gnu.org>
> wrote:
> > If this libstdc++ is
> > newer than the one one the target, I get undefined references
> > (because
> > there are some newer implementation details and things like that). 
> 
> Then you're not telling the executable how find the new libstdc++.
>  
>
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
> 
> 

I tried to do that.  If I let the toolchain use it's own libstdc++.so,
then I get at runtime unresolved symbols due to the version mismatch
(these GLIBCXX errors). This is clear.

If I force the toolchain to link against the older target libstdc++,
then I get undefined symbols at compile time, because it is still using
it's own shipped headers for the newer libstdc++, which have
implementation details that use newer "functions/symbols" that are not
available in the old libstdc++.

If I furthermore remove the shipped headers and force it to include the
c++ headers from the older libstdc++, then everything works out.

But this whole "patching" seems very hacky.

> >  Is
> > it possible to tell G++/GCC to use the libstdc++.so from the target
> > and
> > also to use the C++ headers (like iostream) from the target?
> 
> It's possible, but unsupported and probably won't work.

So it seems to be indeed possible, but not intended.

> 
> > If not, is there any reason this is hard-coded?
> 
> The libstdc++ headers are tightly coupled to the GCC version, so
> headers from a given GCC release might not even compile with a newer
> or older GCC.

I would see an argument if you're trying to compile an newer libstdc++
with an older gcc - but why not the other way around?  C++ in general
tries to be very good in backward compatibility.
This essentially means that you can't use newer compilers with more
features/bugfixes to compile software for older targets.
Is there any obvious reason this is not supported?  Clang, for example,
also seems to be able to compile/link against different libstdc++
versions.  I'm just wondering.

Best,
Anton

Re: Relation between gcc version and libstdc++ version

[Jonathan Wakely]

On Tue, 30 Aug 2022, 17:53 Anton Wöllert, <a.woellert@gmail.com> wrote:

> Hi Jonathan,
>
> thank you for your reply!
>
> On Tue, 2022-08-30 at 17:09 +0100, Jonathan Wakely wrote:
> >
> >
> > On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, <gcc@gcc.gnu.org>
> > wrote:
> > > If this libstdc++ is
> > > newer than the one one the target, I get undefined references
> > > (because
> > > there are some newer implementation details and things like that).
> >
> > Then you're not telling the executable how find the new libstdc++.
> >
> >
> https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
> >
> >
>
> I tried to do that.  If I let the toolchain use it's own libstdc++.so,
> then I get at runtime unresolved symbols due to the version mismatch
> (these GLIBCXX errors). This is clear.
>


Which is the problem described in the above FAQ. And you should solve it
that way. Apparently you haven't done what it says to do, because you
wouldn't get errors if you had done it.

See also the page in the manual that the FAQ links to.



> If I force the toolchain to link against the older target libstdc++,
> then I get undefined symbols at compile time, because it is still using
> it's own shipped headers for the newer libstdc++, which have
> implementation details that use newer "functions/symbols" that are not
> available in the old libstdc++.
>

Yes, that won't work.


> If I furthermore remove the shipped headers and force it to include the
> c++ headers from the older libstdc++, then everything works out.
>
> But this whole "patching" seems very hacky.
>
> > >  Is
> > > it possible to tell G++/GCC to use the libstdc++.so from the target
> > > and
> > > also to use the C++ headers (like iostream) from the target?
> >
> > It's possible, but unsupported and probably won't work.
>
> So it seems to be indeed possible, but not intended.
>
> >
> > > If not, is there any reason this is hard-coded?
> >
> > The libstdc++ headers are tightly coupled to the GCC version, so
> > headers from a given GCC release might not even compile with a newer
> > or older GCC.
>
> I would see an argument if you're trying to compile an newer libstdc++
> with an older gcc - but why not the other way around?


Sometimes the old libstdc++ headers contain invalid C++ which the old GCC
did not diagnose. A newer GCC will give errors when trying to include those
old headers. This is uncommon, but has happened a few times.


  C++ in general
> tries to be very good in backward compatibility.
> This essentially means that you can't use newer compilers with more
> features/bugfixes to compile software for older targets.
>


No it doesn't. Using new compilers on older machines works fine. You just
need to do it right.


Is there any obvious reason this is not supported?  Clang, for example,
> also seems to be able to compile/link against different libstdc++
> versions.  I'm just wondering.



Clang has various hacks to compile the invalid code in old libstdc++
headers. This is necessary for compatibility, because clang doesn't control
which libstdc++ headers are present on a system where clang gets installed.
It has to be prepared to cope with arbitrary libstdc++ versions. That's not
an issue for GCC, because libstdc++ is part of GCC, so if you have a given
version of GCC, then you have the matching libstdc++ headers and libraries,
and you can use them.

Re: Relation between gcc version and libstdc++ version

[Jonathan Wakely]

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

On Tue, 30 Aug 2022, 17:53 Anton Wöllert, <a.woellert@gmail.com> wrote:

> Hi Jonathan,
>
> thank you for your reply!
>
> On Tue, 2022-08-30 at 17:09 +0100, Jonathan Wakely wrote:
> >
> >
> > On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, <gcc@gcc.gnu.org>
> > wrote:
> > > If this libstdc++ is
> > > newer than the one one the target, I get undefined references
> > > (because
> > > there are some newer implementation details and things like that).
> >
> > Then you're not telling the executable how find the new libstdc++.
> >
> >
> https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
> >
> >
>
> I tried to do that.  If I let the toolchain use it's own libstdc++.so,
> then I get at runtime unresolved symbols due to the version mismatch
> (these GLIBCXX errors). This is clear.
>


Which is the problem described in the above FAQ. And you should solve it
that way. Apparently you haven't done what it says to do, because you
wouldn't get errors if you had done it.

See also the page in the manual that the FAQ links to.



> If I force the toolchain to link against the older target libstdc++,
> then I get undefined symbols at compile time, because it is still using
> it's own shipped headers for the newer libstdc++, which have
> implementation details that use newer "functions/symbols" that are not
> available in the old libstdc++.
>

Yes, that won't work.


> If I furthermore remove the shipped headers and force it to include the
> c++ headers from the older libstdc++, then everything works out.
>
> But this whole "patching" seems very hacky.
>
> > >  Is
> > > it possible to tell G++/GCC to use the libstdc++.so from the target
> > > and
> > > also to use the C++ headers (like iostream) from the target?
> >
> > It's possible, but unsupported and probably won't work.
>
> So it seems to be indeed possible, but not intended.
>
> >
> > > If not, is there any reason this is hard-coded?
> >
> > The libstdc++ headers are tightly coupled to the GCC version, so
> > headers from a given GCC release might not even compile with a newer
> > or older GCC.
>
> I would see an argument if you're trying to compile an newer libstdc++
> with an older gcc - but why not the other way around?


Sometimes the old libstdc++ headers contain invalid C++ which the old GCC
did not diagnose. A newer GCC will give errors when trying to include those
old headers. This is uncommon, but has happened a few times.


  C++ in general
> tries to be very good in backward compatibility.
> This essentially means that you can't use newer compilers with more
> features/bugfixes to compile software for older targets.
>


No it doesn't. Using new compilers on older machines works fine. You just
need to do it right.


Is there any obvious reason this is not supported?  Clang, for example,
> also seems to be able to compile/link against different libstdc++
> versions.  I'm just wondering.



Clang has various hacks to compile the invalid code in old libstdc++
headers. This is necessary for compatibility, because clang doesn't control
which libstdc++ headers are present on a system where clang gets installed.
It has to be prepared to cope with arbitrary libstdc++ versions. That's not
an issue for GCC, because libstdc++ is part of GCC, so if you have a given
version of GCC, then you have the matching libstdc++ headers and libraries,
and you can use them.

Re: Relation between gcc version and libstdc++ version

[Jonathan Wakely]

This doesn't belong on this mailing list though, please use the gcc-help
list instead.

This list is for discussion of GCC development, not help using it.


On Tue, 30 Aug 2022, 18:20 Jonathan Wakely, <jwakely.gcc@gmail.com> wrote:

>
>
> On Tue, 30 Aug 2022, 17:53 Anton Wöllert, <a.woellert@gmail.com> wrote:
>
>> Hi Jonathan,
>>
>> thank you for your reply!
>>
>> On Tue, 2022-08-30 at 17:09 +0100, Jonathan Wakely wrote:
>> >
>> >
>> > On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, <gcc@gcc.gnu.org>
>> > wrote:
>> > > If this libstdc++ is
>> > > newer than the one one the target, I get undefined references
>> > > (because
>> > > there are some newer implementation details and things like that).
>> >
>> > Then you're not telling the executable how find the new libstdc++.
>> >
>> >
>> https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
>> >
>> >
>>
>> I tried to do that.  If I let the toolchain use it's own libstdc++.so,
>> then I get at runtime unresolved symbols due to the version mismatch
>> (these GLIBCXX errors). This is clear.
>>
>
>
> Which is the problem described in the above FAQ. And you should solve it
> that way. Apparently you haven't done what it says to do, because you
> wouldn't get errors if you had done it.
>
> See also the page in the manual that the FAQ links to.
>
>
>
>> If I force the toolchain to link against the older target libstdc++,
>> then I get undefined symbols at compile time, because it is still using
>> it's own shipped headers for the newer libstdc++, which have
>> implementation details that use newer "functions/symbols" that are not
>> available in the old libstdc++.
>>
>
> Yes, that won't work.
>
>
>> If I furthermore remove the shipped headers and force it to include the
>> c++ headers from the older libstdc++, then everything works out.
>>
>> But this whole "patching" seems very hacky.
>>
>> > >  Is
>> > > it possible to tell G++/GCC to use the libstdc++.so from the target
>> > > and
>> > > also to use the C++ headers (like iostream) from the target?
>> >
>> > It's possible, but unsupported and probably won't work.
>>
>> So it seems to be indeed possible, but not intended.
>>
>> >
>> > > If not, is there any reason this is hard-coded?
>> >
>> > The libstdc++ headers are tightly coupled to the GCC version, so
>> > headers from a given GCC release might not even compile with a newer
>> > or older GCC.
>>
>> I would see an argument if you're trying to compile an newer libstdc++
>> with an older gcc - but why not the other way around?
>
>
> Sometimes the old libstdc++ headers contain invalid C++ which the old GCC
> did not diagnose. A newer GCC will give errors when trying to include those
> old headers. This is uncommon, but has happened a few times.
>
>
>   C++ in general
>> tries to be very good in backward compatibility.
>> This essentially means that you can't use newer compilers with more
>> features/bugfixes to compile software for older targets.
>>
>
>
> No it doesn't. Using new compilers on older machines works fine. You just
> need to do it right.
>
>
> Is there any obvious reason this is not supported?  Clang, for example,
>> also seems to be able to compile/link against different libstdc++
>> versions.  I'm just wondering.
>
>
>
> Clang has various hacks to compile the invalid code in old libstdc++
> headers. This is necessary for compatibility, because clang doesn't control
> which libstdc++ headers are present on a system where clang gets installed.
> It has to be prepared to cope with arbitrary libstdc++ versions. That's not
> an issue for GCC, because libstdc++ is part of GCC, so if you have a given
> version of GCC, then you have the matching libstdc++ headers and libraries,
> and you can use them.
>
>
>

Re: Relation between gcc version and libstdc++ version

[Jonathan Wakely]

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

This doesn't belong on this mailing list though, please use the gcc-help
list instead.

This list is for discussion of GCC development, not help using it.


On Tue, 30 Aug 2022, 18:20 Jonathan Wakely, <jwakely.gcc@gmail.com> wrote:

>
>
> On Tue, 30 Aug 2022, 17:53 Anton Wöllert, <a.woellert@gmail.com> wrote:
>
>> Hi Jonathan,
>>
>> thank you for your reply!
>>
>> On Tue, 2022-08-30 at 17:09 +0100, Jonathan Wakely wrote:
>> >
>> >
>> > On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, <gcc@gcc.gnu.org>
>> > wrote:
>> > > If this libstdc++ is
>> > > newer than the one one the target, I get undefined references
>> > > (because
>> > > there are some newer implementation details and things like that).
>> >
>> > Then you're not telling the executable how find the new libstdc++.
>> >
>> >
>> https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
>> >
>> >
>>
>> I tried to do that.  If I let the toolchain use it's own libstdc++.so,
>> then I get at runtime unresolved symbols due to the version mismatch
>> (these GLIBCXX errors). This is clear.
>>
>
>
> Which is the problem described in the above FAQ. And you should solve it
> that way. Apparently you haven't done what it says to do, because you
> wouldn't get errors if you had done it.
>
> See also the page in the manual that the FAQ links to.
>
>
>
>> If I force the toolchain to link against the older target libstdc++,
>> then I get undefined symbols at compile time, because it is still using
>> it's own shipped headers for the newer libstdc++, which have
>> implementation details that use newer "functions/symbols" that are not
>> available in the old libstdc++.
>>
>
> Yes, that won't work.
>
>
>> If I furthermore remove the shipped headers and force it to include the
>> c++ headers from the older libstdc++, then everything works out.
>>
>> But this whole "patching" seems very hacky.
>>
>> > >  Is
>> > > it possible to tell G++/GCC to use the libstdc++.so from the target
>> > > and
>> > > also to use the C++ headers (like iostream) from the target?
>> >
>> > It's possible, but unsupported and probably won't work.
>>
>> So it seems to be indeed possible, but not intended.
>>
>> >
>> > > If not, is there any reason this is hard-coded?
>> >
>> > The libstdc++ headers are tightly coupled to the GCC version, so
>> > headers from a given GCC release might not even compile with a newer
>> > or older GCC.
>>
>> I would see an argument if you're trying to compile an newer libstdc++
>> with an older gcc - but why not the other way around?
>
>
> Sometimes the old libstdc++ headers contain invalid C++ which the old GCC
> did not diagnose. A newer GCC will give errors when trying to include those
> old headers. This is uncommon, but has happened a few times.
>
>
>   C++ in general
>> tries to be very good in backward compatibility.
>> This essentially means that you can't use newer compilers with more
>> features/bugfixes to compile software for older targets.
>>
>
>
> No it doesn't. Using new compilers on older machines works fine. You just
> need to do it right.
>
>
> Is there any obvious reason this is not supported?  Clang, for example,
>> also seems to be able to compile/link against different libstdc++
>> versions.  I'm just wondering.
>
>
>
> Clang has various hacks to compile the invalid code in old libstdc++
> headers. This is necessary for compatibility, because clang doesn't control
> which libstdc++ headers are present on a system where clang gets installed.
> It has to be prepared to cope with arbitrary libstdc++ versions. That's not
> an issue for GCC, because libstdc++ is part of GCC, so if you have a given
> version of GCC, then you have the matching libstdc++ headers and libraries,
> and you can use them.
>
>
>

Re: Relation between gcc version and libstdc++ version

[Anton Wöllert]

Thanks for your comments,

sorry for posting on the wrong mailing list.  I'll just restate my
initial question here on gcc-help again:

   I was trying to build a cross-compilation toolchain for a specific
   target using a newer GCC version, than the one that the binaries
   were build on the target.
   
   The C part seems to work well, but the C++ part doesn't.  It seems
   that the G++ ships it's own libstdc++ include headers.  If this
   libstdc++ is newer than the one one the target, I get undefined
   references (because there are some newer implementation details and
   things like that).  Is it possible to tell G++/GCC to use the
   libstdc++.so from the target and also to use the C++ headers (like
   iostream) from the target?
   If not, is there any reason this is hard-coded?
   
   With clang it looks like you can specify "any" libstdc++ version you
   want, although I haven't tested it yet.

On Tue, 2022-08-30 at 18:21 +0100, Jonathan Wakely wrote:
> This doesn't belong on this mailing list though, please use the gcc-
> help list instead.
> 
> This list is for discussion of GCC development, not help using it.
> 
> 
> > > C++ in general
> > > tries to be very good in backward compatibility.
> > > This essentially means that you can't use newer compilers with
> > > more
> > > features/bugfixes to compile software for older targets.
> > 
> > 
> > No it doesn't. Using new compilers on older machines works fine.
> > You just need to do it right.
> > 

So what is the right way to compile software with a newer version of
gcc for a target, that has an older version of gcc?  I can't find any
hints about that in documentation.  Should I ship the newer
libstdc++.so with the application to the target and set
LD_LIBRARY_PATH?  Then I probably also have to add other libraries,
right?


Kind regards,
Anton

Re: Relation between gcc version and libstdc++ version

[Jonathan Wakely]

On Tue, 30 Aug 2022, 19:46 Anton Wöllert, <a.woellert@gmail.com> wrote:

> Thanks for your comments,
>
> sorry for posting on the wrong mailing list.  I'll just restate my
> initial question here on gcc-help again:
>
>    I was trying to build a cross-compilation toolchain for a specific
>    target using a newer GCC version, than the one that the binaries
>    were build on the target.
>
>    The C part seems to work well, but the C++ part doesn't.  It seems
>    that the G++ ships it's own libstdc++ include headers.  If this
>    libstdc++ is newer than the one one the target, I get undefined
>    references (because there are some newer implementation details and
>    things like that).  Is it possible to tell G++/GCC to use the
>    libstdc++.so from the target and also to use the C++ headers (like
>    iostream) from the target?
>    If not, is there any reason this is hard-coded?
>
>    With clang it looks like you can specify "any" libstdc++ version you
>    want, although I haven't tested it yet.
>
> On Tue, 2022-08-30 at 18:21 +0100, Jonathan Wakely wrote:
> > This doesn't belong on this mailing list though, please use the gcc-
> > help list instead.
> >
> > This list is for discussion of GCC development, not help using it.
> >
> >
> > > > C++ in general
> > > > tries to be very good in backward compatibility.
> > > > This essentially means that you can't use newer compilers with
> > > > more
> > > > features/bugfixes to compile software for older targets.
> > >
> > >
> > > No it doesn't. Using new compilers on older machines works fine.
> > > You just need to do it right.
> > >
>
> So what is the right way to compile software with a newer version of
> gcc for a target, that has an older version of gcc?  I can't find any
> hints about that in documentation.  Should I ship the newer
> libstdc++.so with the application to the target and set
> LD_LIBRARY_PATH?


As the documentation says, there are other ways that might be better than
LD_LIBRARY_PATH, but they all require shipping the new libstdc++.so.6 with
the application. Static linking is another option, which avoids needing the
new libstdc++.so.6 at runtime.



  Then I probably also have to add other libraries,
> right?
>

No, you shouldn't need to.


>
> Kind regards,
> Anton
>
>
>

Re: Relation between gcc version and libstdc++ version

[Jonathan Wakely]

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

On Tue, 30 Aug 2022, 19:46 Anton Wöllert, <a.woellert@gmail.com> wrote:

> Thanks for your comments,
>
> sorry for posting on the wrong mailing list.  I'll just restate my
> initial question here on gcc-help again:
>
>    I was trying to build a cross-compilation toolchain for a specific
>    target using a newer GCC version, than the one that the binaries
>    were build on the target.
>
>    The C part seems to work well, but the C++ part doesn't.  It seems
>    that the G++ ships it's own libstdc++ include headers.  If this
>    libstdc++ is newer than the one one the target, I get undefined
>    references (because there are some newer implementation details and
>    things like that).  Is it possible to tell G++/GCC to use the
>    libstdc++.so from the target and also to use the C++ headers (like
>    iostream) from the target?
>    If not, is there any reason this is hard-coded?
>
>    With clang it looks like you can specify "any" libstdc++ version you
>    want, although I haven't tested it yet.
>
> On Tue, 2022-08-30 at 18:21 +0100, Jonathan Wakely wrote:
> > This doesn't belong on this mailing list though, please use the gcc-
> > help list instead.
> >
> > This list is for discussion of GCC development, not help using it.
> >
> >
> > > > C++ in general
> > > > tries to be very good in backward compatibility.
> > > > This essentially means that you can't use newer compilers with
> > > > more
> > > > features/bugfixes to compile software for older targets.
> > >
> > >
> > > No it doesn't. Using new compilers on older machines works fine.
> > > You just need to do it right.
> > >
>
> So what is the right way to compile software with a newer version of
> gcc for a target, that has an older version of gcc?  I can't find any
> hints about that in documentation.  Should I ship the newer
> libstdc++.so with the application to the target and set
> LD_LIBRARY_PATH?


As the documentation says, there are other ways that might be better than
LD_LIBRARY_PATH, but they all require shipping the new libstdc++.so.6 with
the application. Static linking is another option, which avoids needing the
new libstdc++.so.6 at runtime.



  Then I probably also have to add other libraries,
> right?
>

No, you shouldn't need to.


>
> Kind regards,
> Anton
>
>
>