Runtime loader issue

[Steve Kargl]

In review PR 228007, it came to my attention some individuals are
mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
issue". See

https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html

The problem can be summarized by the following

% gfortran7 -o z h.f90
% ./z
/lib/libgcc_s.so.1: version GCC_4.8.0 required by \
/usr/local/lib/gcc7/libgfortran.so.4 not found

gfortran7 is installed from ports/lang/gcc7. This is not
a "gfortran's FreeBSD issue". This is a FreeBSD loader issue.

Specifically, there is a shared library name clash.

% ldconfig -r | grep gcc_
6:-lgcc_s.1 => /lib/libgcc_s.so.1
716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1

% ldd z
z:
libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000)
libm.so.5 => /lib/libm.so.5 (0x200a17000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000)
libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000)
libc.so.7 => /lib/libc.so.7 (0x200ca3000)

So, the runtime loader finds 6 instead of 716, tries to link,
fails, and issues an error message. There are a number ways to
fix this issue.

1) By far, the best solution would be to stop hijacking the libgcc
name in libraries installed on FreeBSD that are not related to
actual GCC software.

% ls -l /lib/libgcc* /usr/lib/libgcc*
(trimming lines)
/lib/libgcc_s.so.1
/usr/lib/libgcc.a@ -> libcompiler_rt.a
/usr/lib/libgcc_eh.a
/usr/lib/libgcc_eh_p.a
/usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a
/usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1

Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm
aware that clang does not work on all archs and the ancient gcc
lives on.

2) Given the expected push back againt solution 1), this solution
proposes bumping the library version for /lib/libgcc_s.so.1 from
1 to some larger value, say, 10. It is unlikely that GCC will
bump its shared library number anytime soon. GCC bumped it from
0 to 1 some 16 years ago.

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316

This solution, however, papers over the general problem with
name clashes.

3) This solution is to actually fix the runtime loader. If an error
occurs with loading a shared library, then iterate over the entries
in the hints file to check to see if another hint would satisfy
the linking. Here, instead of issuing the above error, the loader
would find entry 716, and load the correct libgcc_s.so.1.

Admittedly, I haven't looked to see how difficult this solution
would be.

4) Bump the shared library number of the individual ports. As a proof
of concept, I've done this with ports/lang/gcc6.

% cat /usr/ports/lang/gcc6/files/patch-t-slibgcc
--- libgcc/config/t-slibgcc.orig 2018-05-08 12:47:42.334495000 -0700
+++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700
@@ -20,7 +20,7 @@

SHLIB_EXT = .so
SHLIB_SOLINK = @shlib_base_name@.so
-SHLIB_SOVERSION = 1
+SHLIB_SOVERSION = 2
SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION)
SHLIB_MAP = @shlib_map_file@
SHLIB_OBJS = @shlib_objs@

% ldconfig -r | grep gcc_
6:-lgcc_s.1 => /lib/libgcc_s.so.1
716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1
766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2

% gfortran6 -o z h.f90
% ./z
hello
% ldd z
z:
libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000)
libm.so.5 => /lib/libm.so.5 (0x20096c000)
libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a0000)
libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000)
libc.so.7 => /lib/libc.so.7 (0x200df7000)

This works for this particular name conflict. Hopefully, FreeBSD
never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This,
however, introduces an incompatibility with what is actually distributed
by GCC.

Finally, can people stop referring to the above error as
"gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue.

--
Steve
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Diane Bruce]

On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote:

> On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > In review PR 228007, it came to my attention some individuals are
> > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> > issue". See

Indeed. I've tried to make it clear it is a name conflict with libgcc
in my own bug reports on the subject.

> >
> > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html
> >
> > The problem can be summarized by the following

...

> > gfortran7 is installed from ports/lang/gcc7. This is not
> > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue.
> >
> > Specifically, there is a shared library name clash.
> >
> > % ldconfig -r | grep gcc_
> > 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1

Yep.
See https://wiki.freebsd.org/libgcc%20problem

> >
> > So, the runtime loader finds 6 instead of 716, tries to link,
> > fails, and issues an error message. There are a number ways to
> > fix this issue.
> >
> > 1) By far, the best solution would be to stop hijacking the libgcc
> > name in libraries installed on FreeBSD that are not related to
> > actual GCC software.

Agreed, however this has the side effect of meaning conflicts with libraries
between clang and gcc libs. Notably gfortran and flang use different
conventions for I/O :(

See http://people.FreeeBSD.org/~db/fortran_libs.txt

> >
> > Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm
> > aware that clang does not work on all archs and the ancient gcc
> > lives on.
> >

I've argued for this as well and frankly I still think it is the best
solution all around.

> > 2) Given the expected push back againt solution 1), this solution
> > proposes bumping the library version for /lib/libgcc_s.so.1 from
> > 1 to some larger value, say, 10. It is unlikely that GCC will
> > bump its shared library number anytime soon. GCC bumped it from
> > 0 to 1 some 16 years ago.
> >
> > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316
> >
> > This solution, however, papers over the general problem with
> > name clashes.

Yep. I know work is slowly being done to modernise our libgcc already
but the toolchain folks are busy...

> >
> > 3) This solution is to actually fix the runtime loader. If an error
> > occurs with loading a shared library, then iterate over the entries
> > in the hints file to check to see if another hint would satisfy
> > the linking. Here, instead of issuing the above error, the loader
> > would find entry 716, and load the correct libgcc_s.so.1.

This breaks if the bad libgcc is already linked. We'd have to rip
out the original bindings at run time, then re-bind to a new libgcc.
I looked at the rtld code months ago. Nasty and silly.

> >
> > Admittedly, I haven't looked to see how difficult this solution
> > would be.

Very ;)

> >
> > 4) Bump the shared library number of the individual ports. As a proof
> > of concept, I've done this with ports/lang/gcc6.
> >

...

> >
> > Finally, can people stop referring to the above error as
> > "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue.

Yes, please. I tracked it down to libgcc months ago, made my findings
generally available and yet people are still calling it a libgfortran problem.

> >
>
> Our libgcc also lacks some functionality compared to the original one:
> https://reviews.freebsd.org/D11482

Yes.


Diane
--
- d...@FreeBSD.org d...@db.net http://www.db.net/~db

[Steve Kargl]

On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote:
> On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote:
> > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
> > s...@troutmask.apl.washington.edu> wrote:
> >
> > > In review PR 228007, it came to my attention some individuals are
> > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> > > issue". See
>
> Indeed. I've tried to make it clear it is a name conflict with libgcc
> in my own bug reports on the subject.
>
> > >
> > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html
> > >
> > > The problem can be summarized by the following
> ...
> > > gfortran7 is installed from ports/lang/gcc7. This is not
> > > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue.
> > >
> > > Specifically, there is a shared library name clash.
> > >
> > > % ldconfig -r | grep gcc_
> > > 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> > > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1
>
> Yep.
> See https://wiki.freebsd.org/libgcc%20problem
>

Interesting page. I was aware that in the past you tried working
out a solution to the problem. I did not realize you docoumented
the issue. A few corrections to your wiki page.

1) The correct spelling of the name of the language is Fortran (with a
capital F). It has been the official standard spelling since Fortran
90.

2) You have "... to always support quad math (*8) and ...". Quad
precision in gfortran is REAL(16) (the REAL*16 notation is nonstandard).

3) "subsitute" is normally spelled with an extra 't'. :-)

> > > So, the runtime loader finds 6 instead of 716, tries to link,
> > > fails, and issues an error message. There are a number ways to
> > > fix this issue.
> > >
> > > 1) By far, the best solution would be to stop hijacking the libgcc
> > > name in libraries installed on FreeBSD that are not related to
> > > actual GCC software.
>
> Agreed, however this has the side effect of meaning conflicts with libraries
> between clang and gcc libs. Notably gfortran and flang use different
> conventions for I/O :(
>
> See http://people.FreeeBSD.org/~db/fortran_libs.txt
>

Page doesn't appear to exist? If I go to

https://people.freebsd.org/homepage.html

you're not listed.

Just started reading the source code. Don't scare the unwary. :-)

--
Steve

[Kurt Lidl]

On 5/10/18 11:15 AM, Steve Kargl wrote:
> On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote:
>>
>> Agreed, however this has the side effect of meaning conflicts with libraries
>> between clang and gcc libs. Notably gfortran and flang use different
>> conventions for I/O :(
>>
>> See http://people.FreeeBSD.org/~db/fortran_libs.txt
>>
>
> Page doesn't appear to exist? If I go to
>
> https://people.freebsd.org/homepage.html
>
> you're not listed.

There's one too many "e" characters in the given URI.

Correct URI: http://people.FreeBSD.org/~db/fortran_libs.txt

-Kurt

[Steve Kargl]

On Thu, May 10, 2018 at 11:23:39AM -0400, Kurt Lidl wrote:
> On 5/10/18 11:15 AM, Steve Kargl wrote:
> > On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote:
> >>
> >> Agreed, however this has the side effect of meaning conflicts with libraries
> >> between clang and gcc libs. Notably gfortran and flang use different
> >> conventions for I/O :(
> >>
> >> See http://people.FreeeBSD.org/~db/fortran_libs.txt
> >
> > Page doesn't appear to exist? If I go to
> >
> > https://people.freebsd.org/homepage.html
> >
> > you're not listed.
>
> There's one too many "e" characters in the given URI.
>
> Correct URI: http://people.FreeBSD.org/~db/fortran_libs.txt
>

Ah, thanks! I simply copy-n-pasted the link, then went to
the homepage.html via a bookmark.

The incompatibility in IO runtimes between gfortran and
flang is a minor issue for anyone using actual modern
Fortran, and in particular, Fortran's MODULE feature.

% cat m.f90
module foo
implicit none
real :: pi = 3.14
contains
function real_pi() result(p)
real p
p = atan(1.)
end function real_pi
end module foo
% gfortran6 -c m.f90
% nm m.o
0000000000000000 D __foo_MOD_pi
0000000000000000 T __foo_MOD_real_pi
% file foo.mod
foo.mod: gzip compressed data, from Unix
% flang -c m.f90
% nm m.o
0000000000000000 r .C288_foo_real_pi_
0000000000000000 r .LCPI1_0
0000000000000000 D _foo_8_
0000000000000000 T foo_
0000000000000010 T foo_real_pi_
% file foo.mod
foo.mod: ASCII text

foo.mod can be thought of as a pre-compile header.
It will encode the named constant pi and a signature
for the function real_pi. The object files contain
name-mangled entry points for the function. The
Fortran Standard(s) do not specify implementation detail,
so there is an incompatibility between not only
gfortran and flang, but all Fortran compiler vendors.

--
Steve

[Joerg Sonnenberger]

On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote:
> In review PR 228007, it came to my attention some individuals are
> mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> issue".

I don't get why you are blaming the FreeBSD loader. In fact, this is a
pretty common issue and the fault is and has always been that the GCC
ecosystem is extremely bad about mixing different GCC versions in the
runtime environment. It tends to somewhat work as long as you make sure
that the main binary is using the newest GCC version, but it can still
fail even then.

Joerg

[Wojciech Puchar]

just another - out of thousands - example that shared libraries are one
of the worst thing invented in computing.

Maybe except of single system wide shared library with constant interface.

On Thu, 10 May 2018, Gleb Popov wrote:

> On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>

> Our libgcc also lacks some functionality compared to the original one:
> https://reviews.freebsd.org/D11482
>
>

>> --
>> Steve
>> _______________________________________________
>> freebsd...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>>

> _______________________________________________
> freebs...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-port...@freebsd.org"

[Steve Kargl]

On Thu, May 10, 2018 at 09:05:49PM +0200, Joerg Sonnenberger wrote:
> On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote:
> > In review PR 228007, it came to my attention some individuals are
> > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> > issue".
>
> I don't get why you are blaming the FreeBSD loader. In fact, this is a
> pretty common issue and the fault is and has always been that the GCC
> ecosystem is extremely bad about mixing different GCC versions in the
> runtime environment. It tends to somewhat work as long as you make sure
> that the main binary is using the newest GCC version, but it can still
> fail even then.
>

It is a runtime loader issue in that the loader cannot not
deal with a name clash. Suppose project Ajax has libfoo.so.1
and project Nub has libfoo.so.1. You install Ajax first,
ldconfig will find

42:-lfoo.1 => /usr/local/lib/ajax/libfoo.so.1

while project Nub's libfoo.so.1 is

666:-lfoo.1 => /usr/local/lib/nub/libfoo.so.1

You build your Nub project bar and go to execute bar
where upon the runtime loader finds 42 instead of 666.

Tijl's suggested fix of re-ordering the list of hints so
gcc7's libgcc_s.so.1 is found before /lib/libgcc_s.so.1
works around the issue of executables compiled by gfortran7
getting the correct libgcc_s.so.1. It does not solve the
above problem, because once re-ordered, anything compiled
by the ajax project finds the wrong libfoo.so.1 library.

As to your comment "the fault is and has always been that

the GCC ecosystem is extremely bad about mixing different

GCC version". libgcc_s.so.1 is a symbol versioned shared
library. As long as the ABI of symbols are not changed,
one can add new symbols without bumping the library version
number. GCC has added symbols to libgcc_s.so.1 since gcc
4.2.1, and FreeBSD has not stayed in-sync.

If you want to get snarky about different projects, don't
you think that "the fault is and has always been that the
FreeBSD ecosystem" (mis)appropriated the name libgcc when
clang came into the tree [1] because clang didn't have a
runtime library [2] and it was expedient to simply use
libgcc_s.so.1.

[1] llvm+clang
Added Tue Jun 2 17:58:47 2009 UTC (8 years, 11 months ago) by ed
https://svnweb.freebsd.org/base?view=revision&revision=193326

[2] compiler-rt.
Added Thu Oct 21 19:02:02 2010 UTC (7 years, 6 months ago) by ed
https://svnweb.freebsd.org/base?view=revision&revision=214152

--
Steve

[Joerg Sonnenberger]

On Thu, May 10, 2018 at 12:48:23PM -0700, Steve Kargl wrote:
> On Thu, May 10, 2018 at 09:05:49PM +0200, Joerg Sonnenberger wrote:
> > On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote:
> > > In review PR 228007, it came to my attention some individuals are
> > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> > > issue".
> >
> > I don't get why you are blaming the FreeBSD loader. In fact, this is a
> > pretty common issue and the fault is and has always been that the GCC
> > ecosystem is extremely bad about mixing different GCC versions in the
> > runtime environment. It tends to somewhat work as long as you make sure
> > that the main binary is using the newest GCC version, but it can still
> > fail even then.
> >
>
> It is a runtime loader issue in that the loader cannot not
> deal with a name clash.

It is not supposed to. The soname identifies the object. If you end up
with multiple different objects with the same soname, it is your fault.
It's not something the loader can magically fix.

> Tijl's suggested fix of re-ordering the list of hints so
> gcc7's libgcc_s.so.1 is found before /lib/libgcc_s.so.1
> works around the issue of executables compiled by gfortran7
> getting the correct libgcc_s.so.1.

It doesn't solve the problem because it assumes that gfortran7's
libgcc_so.so.1 is a superset of /lib/libgcc_s.so.1. This is a very
popular assumption in GCCland and it turns out to be false surprisingly
often.

> As to your comment "the fault is and has always been that
> the GCC ecosystem is extremely bad about mixing different
> GCC version". libgcc_s.so.1 is a symbol versioned shared
> library. As long as the ABI of symbols are not changed,
> one can add new symbols without bumping the library version
> number. GCC has added symbols to libgcc_s.so.1 since gcc
> 4.2.1, and FreeBSD has not stayed in-sync.

This is missing the point. GCC assumes that it always gets its own
version of libgcc_s.so, because of course you are always going to
compile things with the newest GCC in your system. Ironically, symbol
versioning makes this situation *worse*, because symbol lookup no longer
falls through consistently.

> If you want to get snarky about different projects, don't
> you think that "the fault is and has always been that the
> FreeBSD ecosystem" (mis)appropriated the name libgcc when
> clang came into the tree [1] because clang didn't have a
> runtime library [2] and it was expedient to simply use
> libgcc_s.so.1.

Again, you are missing that the situation would happen just the same if
the base compiler is GCC 4.2.1 and not Clang.

Joerg

[Steve Kargl]

On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote:
>
> Again, you are missing that the situation would happen just the same if
> the base compiler is GCC 4.2.1 and not Clang.
>

FreeBSD could have stayed in-step with the times.

--
Steve

[Joerg Sonnenberger]

On Thu, May 10, 2018 at 01:25:36PM -0700, Steve Kargl wrote:
> On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote:
> >
> > Again, you are missing that the situation would happen just the same if
> > the base compiler is GCC 4.2.1 and not Clang.
> >
>
> FreeBSD could have stayed in-step with the times.

FreeBSD or any other system could be updated the GCC version for every
release and there would still appear a newer GCC version that requires
an even newer libgcc_s.so in the release life time. Heck, the very same
problem happens in the other direction as well, i.e. if you are forced
to use an *older* GCC and pick up its libgcc_s.so.

Joerg

[Steve Kargl]

On Thu, May 10, 2018 at 11:01:57PM +0200, Joerg Sonnenberger wrote:
> On Thu, May 10, 2018 at 01:25:36PM -0700, Steve Kargl wrote:
> > On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote:
> > >
> > > Again, you are missing that the situation would happen just the same if
> > > the base compiler is GCC 4.2.1 and not Clang.
> > >
> >
> > FreeBSD could have stayed in-step with the times.
>
> FreeBSD or any other system could be updated the GCC version for every
> release and there would still appear a newer GCC version that requires
> an even newer libgcc_s.so in the release life time. Heck, the very same
> problem happens in the other direction as well, i.e. if you are forced
> to use an *older* GCC and pick up its libgcc_s.so.
>

If, as you assert, FreeBSD's runtime loader isn't meant
to deal with name clashes, then why does ldconfig place
conflicting names into the list of hints?

% ldconfig -r | grep libgcc_s

6:-lgcc_s.1 => /lib/libgcc_s.so.1
716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1

Shouldn't ldconfig refuse to add 716 and complain
bitterly to the user to fix the conflict? Shouldn't
the documentation that comes with FreeBSD explain that
conflicting names are disallowed.

In looking at an objdump of lib/gcc7/libgfortran.so.4,
one finds

Dynamic Section:
NEEDED libquadmath.so.0
NEEDED libm.so.5
NEEDED libgcc_s.so.1
NEEDED libc.so.7
SONAME libgfortran.so.4
RPATH /usr/local/lib/gcc7

Why isn't the runtime loader looking in RPATH for the
libraries and then falling back to looking in the list
of hints.

I find your arguments to be somewhat diminished by the fact
FreeBSD re-uses a filename from a well-known and (much) older
software project, and somehow its the other project's fault
for the problem with a name clash.

--
Steve

[Lucas Nali de Magalhães]

> On May 10, 2018, at 2:01 PM, Joerg Sonnenberger <jo...@bec.de> wrote:
>
>> On Thu, May 10, 2018 at 01:25:36PM -0700, Steve Kargl wrote:
>>> On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote:
>>>
>>> Again, you are missing that the situation would happen just the same if
>>> the base compiler is GCC 4.2.1 and not Clang.
>>
>> FreeBSD could have stayed in-step with the times.
>
> FreeBSD or any other system could be updated the GCC version for every
> release and there would still appear a newer GCC version that requires
> an even newer libgcc_s.so in the release life time. Heck, the very same
> problem happens in the other direction as well, i.e. if you are forced
> to use an *older* GCC and pick up its libgcc_s.so.

Hi.

This libgcc issue is a little recurrent here in FreeBSD. I remember other email threads talking about it. The summary I remember is that we must go the way Linux does it, I think. It was thoroughly explained in past threads.

As GCC was/is omnipresent in Unix like systems most of the other projects have standard ways to use the libgcc. I used to think in new libgcc as a drop in replacement for older ones. I know this is a bit simplistic. I remember Linux usually uses just one libgcc at a time, too. This is the winning answer usually here, too. In fact I remember that new libgcc versions triggers systems recompilations for safety reasons.

The use of libgcc in FreeBSD makes the procedure unusually complex many times here. It's a source of many problems. This one is one more to add to the list. This just occurred to me now. Please, keep in mind that the case here is caused by the odd use given to this library here.

Lc

--
rollingbits — 📧 rolli...@gmail.com 📧 rolli...@terra.com.br 📧 rolli...@yahoo.com 📧 rolli...@globo.com 📧 rolli...@icloud.com