On 08/24/2018 04:37 PM, Michael Matz wrote:
> Hi,
>
> On Fri, 24 Aug 2018, Martin Liška wrote:
>
>> If I see correctly, for libgcc has following files:
>>
>> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc_eh.a
>> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a
>
On Fri, 24 Aug 2018, Martin Liška wrote:
> > Any symlinks need to be *relative*, not absolute, so the install tree is
> > relocatable. There's unlibsubdir / libsubdir_to_prefix in gcc/Makefile.in
> > but I'm not sure if that's available in the libgcc/ directory at present.
> >
>
> Well I'm no
Hi,
On Fri, 24 Aug 2018, Martin Liška wrote:
> If I see correctly, for libgcc has following files:
>
> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc_eh.a
> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a
> /home/marxin/bin/gcc/lib64/libgcc_s.so.1
> /home/marxi
On 08/24/2018 04:25 PM, Martin Liška wrote:
> On 08/24/2018 03:56 PM, Michael Matz wrote:
>> Hi,
>>
>> On Fri, 24 Aug 2018, Martin Liška wrote:
>>
> Where
> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so
> points to /home/marxin/bin/gcc/lib64/libgcov.so.1 ?
>
On 08/24/2018 03:56 PM, Michael Matz wrote:
> Hi,
>
> On Fri, 24 Aug 2018, Martin Liška wrote:
>
Where
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so
points to /home/marxin/bin/gcc/lib64/libgcov.so.1 ?
>>>
>>> Any symlinks need to be *relative*, not absolute,
Hi,
On Fri, 24 Aug 2018, Martin Liška wrote:
> >> Where
> >> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so
> >> points to /home/marxin/bin/gcc/lib64/libgcov.so.1 ?
> >
> > Any symlinks need to be *relative*, not absolute, so the install tree
> > is relocatable. There's
On 08/17/2018 02:59 PM, Joseph Myers wrote:
> On Fri, 17 Aug 2018, Martin Liška wrote:
>
>> Where /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so
>> points to
>> /home/marxin/bin/gcc/lib64/libgcov.so.1 ?
>
> Any symlinks need to be *relative*, not absolute, so the install tre
On Fri, 17 Aug 2018, Martin Liška wrote:
> Where /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so
> points to
> /home/marxin/bin/gcc/lib64/libgcov.so.1 ?
Any symlinks need to be *relative*, not absolute, so the install tree is
relocatable. There's unlibsubdir / libsubdir_to_
Hello.
On 08/16/2018 03:29 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 16 Aug 2018, Martin Liška wrote:
>
>> SHLIB_SOVERSION = 1
>> SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION)
>>
>> which would require a substitution for soversion, show I generalize even
>> so much?
>
> I wouldn't bot
Hi,
On Thu, 16 Aug 2018, Joseph Myers wrote:
> On Thu, 16 Aug 2018, Michael Matz wrote:
>
> > > About the location of libgcov.{a,so}, I believe right place would be now:
> > >
> > > /home/marxin/bin/gcc/lib64/libgcov.so.1
> > > /home/marxin/bin/gcc/lib64/libgcov.so
> > > /home/marxin/bin/gcc/li
On Thu, 16 Aug 2018, Michael Matz wrote:
> > About the location of libgcov.{a,so}, I believe right place would be now:
> >
> > /home/marxin/bin/gcc/lib64/libgcov.so.1
> > /home/marxin/bin/gcc/lib64/libgcov.so
> > /home/marxin/bin/gcc/lib64/libgcov.a
>
> No. With version dependend dirs the .so s
On Thu, 16 Aug 2018, Martin Liška wrote:
> About the location of libgcov.{a,so}, I believe right place would be now:
>
> /home/marxin/bin/gcc/lib64/libgcov.so.1
> /home/marxin/bin/gcc/lib64/libgcov.so
> /home/marxin/bin/gcc/lib64/libgcov.a
Yes, I think so.
> Because of LD_LIBRARY_PATH location
Hi,
On Thu, 16 Aug 2018, Martin Liška wrote:
> SHLIB_SOVERSION = 1
> SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION)
>
> which would require a substitution for soversion, show I generalize even
> so much?
I wouldn't bother. libgcov.so.1 sounds just fine, and due to symbol
versioning w
On 08/14/2018 10:35 PM, Joseph Myers wrote:
> On Tue, 14 Aug 2018, Martin Liška wrote:
>
>> 2) Do I understand that correctly that I need to build .o files twice:
>> once with hidden visibility and second time without for the shared
>> library?
>
> Yes.
>
Done that, maybe there's a more simpl
On 08/14/2018 03:40 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 14 Aug 2018, Martin Liška wrote:
>
>> I'm sending second version of the patch candidate. I was able to create
>> a mapfile and generate versioned symbols for libgcov.so file.
>>
>> Unresolved issues:
>> 1) I still see linking with stat
On Tue, 14 Aug 2018, Martin Liška wrote:
> 2) Do I understand that correctly that I need to build .o files twice:
> once with hidden visibility and second time without for the shared
> library?
Yes.
--
Joseph S. Myers
jos...@codesourcery.com
Hi,
On Tue, 14 Aug 2018, Martin Liška wrote:
> I'm sending second version of the patch candidate. I was able to create
> a mapfile and generate versioned symbols for libgcov.so file.
>
> Unresolved issues:
> 1) I still see linking with static library:
>
> $ find /home/marxin/bin/gcc -name libgc
On 08/03/2018 04:42 PM, Joseph Myers wrote:
> On Fri, 3 Aug 2018, Jakub Jelinek wrote:
>
>>> 3) Should I come up with a symbol versioning of the libgcov API?
>>
>> Certainly.
>
> Furthermore, make sure that the libgcov.a symbols remain hidden (via
> building the static objects with $(vis_hide),
On Fri, 3 Aug 2018, Martin Liška wrote:
> I'm attaching current patch, so any comment is welcomed.
Please consider passing -Wl,-z,now when linking the new shared library:
gcov has a few thread-local variables that may be accessed in async-signal
context, and Glibc has bugs related to lazy binding
On Fri, 3 Aug 2018, Jakub Jelinek wrote:
> > 3) Should I come up with a symbol versioning of the libgcov API?
>
> Certainly.
Furthermore, make sure that the libgcov.a symbols remain hidden (via
building the static objects with $(vis_hide), since you're removing
ATTRIBUTE_HIDDEN).
--
Joseph S
On Fri, Aug 03, 2018 at 11:23:06AM +0200, Martin Liška wrote:
> I created a working prototype and as it's my first time I'm creating a shared
> library in GCC, I've got multiple questions:
>
> 1) currently both libgcov.so and libgcov.a are installed in an install folder
> and
> when using: gcc ma
Hi.
I've started working on introduction of a new shared library for GCOV.
Justification is PR84107 where libgcov does not properly work properly
for multiple DSOs.
I created a working prototype and as it's my first time I'm creating a shared
library in GCC, I've got multiple questions:
1) curre
22 matches
Mail list logo
