STLport

STLport

[Grant Gray]

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

Hi list, 


Is anyone working on getting STLport working with musl? 


I had a quick look at the STLport sources and it seems to assume glibc is in use if the toolchain is GCC, so it seems some porting effort is required to get it working with musl. 


Grant. 


[-- Attachment #2: Type: text/html, Size: 528 bytes --]

Re: STLport

[Luca Barbato]

On 31/12/12 02:11, Grant Gray wrote:
> Hi list, 
> 
> 
> Is anyone working on getting STLport working with musl? 
> 
> 

What about libc++ from llvm?

lu

Re: STLport

[Rich Felker]

On Mon, Dec 31, 2012 at 12:11:18PM +1100, Grant Gray wrote:
> Hi list, 
> 
> 
> Is anyone working on getting STLport working with musl? 
> 
> 
> I had a quick look at the STLport sources and it seems to assume
> glibc is in use if the toolchain is GCC, so it seems some porting
> effort is required to get it working with musl.

Is there a reason you want to use STLport rather than libstdc++ or
libc++? My impression was that STLport was outdated, unmaintained, and
full of ugly legacy hackery from the 90s...

Rich

Re: STLport

[idunham]

> On Mon, Dec 31, 2012 at 12:11:18PM +1100, Grant Gray wrote:
>> Hi list,
>>
>>
>> Is anyone working on getting STLport working with musl?
>>
>>
>> I had a quick look at the STLport sources and it seems to assume
>> glibc is in use if the toolchain is GCC, so it seems some porting
>> effort is required to get it working with musl.
>
> Is there a reason you want to use STLport rather than libstdc++ or
> libc++? My impression was that STLport was outdated, unmaintained, and
> full of ugly legacy hackery from the 90s...

The last tarball is from 2008.  So yes, I'd call it unmaintained.  Even
DJGPP's GCC is more current than that.

Re: STLport

[Grant Gray]

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

> On Mon, Dec 31, 2012 at 12:11:18PM +1100, Grant Gray wrote:
> > Hi list,
> >
> >
> > Is anyone working on getting STLport working with musl?
> >
> >
> > I had a quick look at the STLport sources and it seems to assume
> > glibc is in use if the toolchain is GCC, so it seems some porting
> > effort is required to get it working with musl.

> Is there a reason you want to use STLport rather than libstdc++ or
> libc++? My impression was that STLport was outdated, unmaintained,
> and
> full of ugly legacy hackery from the 90s...

> Rich

Licensing is the issue. I'm building a userland free of copyleft code, which rules out libstdc++. I haven't investigated libc++, but I have no allegiance to STLport so will look into it. 

Is anyone already working on a libc++ integration with musl? 

[-- Attachment #2: Type: text/html, Size: 1584 bytes --]

Re: STLport

[Rich Felker]

On Mon, Dec 31, 2012 at 02:00:53PM +1100, Grant Gray wrote:
> Licensing is the issue. I'm building a userland free of copyleft
> code, which rules out libstdc++. I haven't investigated libc++, but
> I have no allegiance to STLport so will look into it.

I think libc++ would be a much better choice. Even if it ends up being
more work, it's actually modern/up-to-date and it's a library
everybody wants to support anyway. And it purportedly aims to be
portable (not sure if this is really true), so it shouldn't be so bad
to get it working with musl.

> Is anyone already working on a libc++ integration with musl? 

I know several people have experimented with using llvm/clang with
musl, but I don't know what the status on libc++ is.

Rich

Re: STLport

[agent]

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

31.12.2012 09:00, Grant Gray пишет:
>
>     On Mon, Dec 31, 2012 at 12:11:18PM +1100, Grant Gray wrote:
>     > Hi list,
>     >
>     >
>     > Is anyone working on getting STLport working with musl?
>     >
>     >
>     > I had a quick look at the STLport sources and it seems to assume
>     > glibc is in use if the toolchain is GCC, so it seems some porting
>     > effort is required to get it working with musl.
>
>     Is there a reason you want to use STLport rather than libstdc++ or
>     libc++? My impression was that STLport was outdated, unmaintained, and
>     full of ugly legacy hackery from the 90s...
>
>     Rich
>
> Licensing is the issue. I'm building a userland free of copyleft code, 
> which rules out libstdc++. I haven't investigated libc++, but I have 
> no allegiance to STLport so will look into it.
>
> Is anyone already working on a libc++ integration with musl?
>
i have tried to build the whole stack: clang, libc++, libc++abi with 
musl, though i got stuck with libunwind for libc++abi. libc++ compiled 
fine when using libsupc++, but i didn't test it anyhow (maybe it is even 
unusable). i'm going to try out clang + libc++ + libcxxrt + musl 
soon.they say libc++ works with libcxxrt and libcxxrt has it's own unwind.

[-- Attachment #2: Type: text/html, Size: 3258 bytes --]

Re: STLport

[Daniel Cegiełka]

perhaps gcc-5 will be more modular (like LLVM stuff):

http://www.phoronix.com/scan.php?page=news_item&px=MTA3MzE

Daniel

Re: STLport

[Rich Felker]

On Mon, Dec 31, 2012 at 08:57:59AM +0100, Daniel Cegiełka wrote:
> perhaps gcc-5 will be more modular (like LLVM stuff):
> 
> http://www.phoronix.com/scan.php?page=news_item&px=MTA3MzE

Likely so, but this is not a good thing...

Rich

Re: STLport

[Rich Felker]

On Mon, Dec 31, 2012 at 12:33:00PM +0600, agent wrote:
> >Is anyone already working on a libc++ integration with musl?
> >
> i have tried to build the whole stack: clang, libc++, libc++abi with
> musl, though i got stuck with libunwind for libc++abi. libc++
> compiled fine when using libsupc++, but i didn't test it anyhow
> (maybe it is even unusable). i'm going to try out clang + libc++ +
> libcxxrt + musl soon.they say libc++ works with libcxxrt and
> libcxxrt has it's own unwind.

We seem to be _almost_ to the point of having libunwind working now.
The only failure I'm still seeing is missing sigreturn/setcontext,
which are referenced from src/x86/Gos-linux.c. Adding the full
ucontext stuff would be a pain (lots of arch-specific code), but we
could cheat and handle just setcontext with minimal code by letting
the kernel do all the work (it requires a syscall anyway to set the
signal mask, so we might as well let the kernel do all the work by
implementing setcontext in terms of SYS_rt_sigreturn).

With that said, I suspect the function in src/x86/Gos-linux.c that's
using sigreturn and setcontext is utterly useless; its purpose seems
to be unwinding across signal handler boundaries, which cannot happen
in correct programs anyway. Replacing the whole function with
something like *(volatile char *)0=0; (i.e. crash) should get you a
working libunwind.

Rich