Hi, thanks for reporting this bug.
Assigned to the package maintainer.

Keywords: (none) => PATCH, Triaged
See Also: (none) => https://bugs.gentoo.org/show_bug.cgi?id=332905
Assignee: bugsquad => tmb
Source RPM: (none) => lvm2

(In reply to comment #1)
> Hi, thanks for reporting this bug.
> Assigned to the package maintainer.

Well, you've set the package to "lvm2", but it's a global problem with GNU ld that I've ran into with my own code.

Regards,

-- Shlomi Fish

Assigning to the correct package - "binutils", as it is a problem with /usr/bin/ld.

Source RPM: lvm2 => binutils

Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED.

@ tmb

Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.

CC: (none) => marja11

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

This bug still exists in Mageia Linux Cauldron (also in Mageia 2). Removing "NEEDINFO".

Keywords: NEEDINFO => (none)
Whiteboard: (none) => MGA2TOO

Sorry, but this bug saw no action since over 2 yrs ago. 
No cauldron package has stayed the same since then.

Closing as OLD

Please reopen if this report is still valid for _current_ cauldron and/or fully
updated Mageia 4

Status: NEW => RESOLVED
Resolution: (none) => OLD

Still happens on Mageia Cauldron x86-64 (What will become Mageia 5):

shlomif[fcs]:$trunk/fc-solve/B$ make -f ../source/Makefile.gnu SRC_DIR=$(pwd)/../source 
gcc -Wall -DFCS_DBM_USE_LIBAVL=1 -I. -I/home/shlomif/progs/freecell/git/fc-solve/fc-solve/B/../source/libavl/ -I/home/shlomif/progs/freecell/git/fc-solve/fc-solve/B/../source -I/home/shlomif/progs/freecell/git/fc-solve/fc-solve/B/../source/patsolve-shlomif/patsolve -Werror=implicit-function-declaration -std=gnu99 -g -fPIC -DFCS_FREECELL_ONLY=1  -fwhole-program -o fc-solve -Wl,-rpath,. -L. main.o -lfcs -pg -lc_p -lm_p -static-libgcc
/usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/gcc/x86_64-mageia-linux-gnu/4.9.2/../../../../lib64/libc_p.a(strcmp.op)' can not be used when making an executable; recompile with -fPIE and relink with -pie
collect2: error: ld returned 1 exit status
../source/Makefile.gnu:252: recipe for target 'fc-solve' failed
make: *** [fc-solve] Error 1
shlomif[fcs]:$trunk/fc-solve/B$ 

Reopening.

Status: RESOLVED => REOPENED
Resolution: OLD => (none)

(In reply to Shlomi Fish from comment #9)

> 
> Reopening.

I suppose that Gentoo patch is useless, because it is about patching lvm2 instead of binutils.

Removing the link.

I don't see anything in RedHat bugzilla about this issue in Fedora 20 or later. 
That might be because I didn't search well enough. 
However, if you do have a Rawhide (or 21 or 20) at hand: does it fail there, too?

Keywords: PATCH => (none)
See Also: https://bugs.gentoo.org/show_bug.cgi?id=332905 => (none)
Whiteboard: MGA2TOO => MGA4TOO

(In reply to Marja van Waes from comment #10)
> (In reply to Shlomi Fish from comment #9)
> 
> > 
> > Reopening.
> 
> I suppose that Gentoo patch is useless, because it is about patching lvm2
> instead of binutils.
> 
> Removing the link.
> 
> I don't see anything in RedHat bugzilla about this issue in Fedora 20 or
> later. 
> That might be because I didn't search well enough. 
> However, if you do have a Rawhide (or 21 or 20) at hand: does it fail there,
> too?

I will test it in a VM and let you know.

Thanks!

An update, I have installed a Fedora 21 x86-64 VM and discovered that the glibc-profile package there is no longer available for it. I can try it with what is reported at https://bugzilla.redhat.com/show_bug.cgi?id=642999 and check the static library. Will that be adequate?

(In reply to Shlomi Fish from comment #12)
> An update, I have installed a Fedora 21 x86-64 VM and discovered that the
> glibc-profile package there is no longer available for it. I can try it with
> what is reported at https://bugzilla.redhat.com/show_bug.cgi?id=642999 and
> check the static library. Will that be adequate?

Sorry, I don't have the slightest idea. Maybe the assignee can tell, but he might be too busy fixing things that affect many more users.

You'll have a much better understanding of static vs dynamic than I have.
In case you didn't read that, here https://bugzilla.redhat.com/show_bug.cgi?id=785399#c20 someone with a similar llvm2 issue, decided to forget about static. Don't know whether that is of any use?

@ Shlomi

Is this bug still valid?

Keywords: Triaged => NEEDINFO
Assignee: tmb => basesystem
Whiteboard: MGA4TOO => (none)

Hi Marja,

(In reply to Marja van Waes from comment #14)
> @ Shlomi
> 
> Is this bug still valid?

this still happens on MGA6/Cauldron:

shlomif[fcs]:$trunk/fc-solve/profile-b$ make -f ../source/Makefile.gnu SRC_DIR=../source  
gcc -O3 -DNDEBUG -fvisibility=hidden -march=native -fomit-frame-pointer -flto -ffat-lto-objects -fwhole-program  -o fc-solve  main.o -rdynamic libfcs.a -pg -lc_p -lm_p -static-libgcc
/usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/gcc/x86_64-mageia-linux-gnu/5.4.0/../../../../lib64/libc_p.a(strcmp.op)' can not be used when making an executable; recompile with -fPIE and relink with -pie
collect2: error: ld returned 1 exit status
../source/Makefile.gnu:243: recipe for target 'fc-solve' failed
make: *** [fc-solve] Error 1
shlomif[fcs]:$trunk/fc-solve/profile-b$ git dh
diff --git a/fc-solve/source/Makefile.gnu b/fc-solve/source/Makefile.gnu
index 745955e..e238921 100644
--- a/fc-solve/source/Makefile.gnu
+++ b/fc-solve/source/Makefile.gnu
@@ -1,5 +1,5 @@
-DEBUG = 0
-PROFILE = 0
+DEBUG = 1
+PROFILE = 1
 WITH_TRACES = 0
 FREECELL_ONLY = 1
 DISABLE_PATSOLVE = 1
@@ -142,8 +142,8 @@ ifneq ($(PROFILE),0)
                END_LFLAGS := -lm -lprofiler
        else
                END_OFLAGS := -pg
-               # END_LFLAGS := -pg -lc_p -lm_p -static-libgcc
-               END_LFLAGS := -pg -lm
+               END_LFLAGS := -pg -lc_p -lm_p -static-libgcc
+               # END_LFLAGS := -pg -lm
        endif
 endif
 
shlomif[fcs]:$trunk/fc-solve/profile-b$

Keywords: NEEDINFO => (none)

(In reply to Shlomi Fish from comment #15)
> Hi Marja,
> 
> (In reply to Marja van Waes from comment #14)
> > @ Shlomi
> > 
> > Is this bug still valid?
> 
> this still happens on MGA6/Cauldron:
> 
> shlomif[fcs]:$trunk/fc-solve/profile-b$ make -f ../source/Makefile.gnu
> SRC_DIR=../source  
> gcc -O3 -DNDEBUG -fvisibility=hidden -march=native -fomit-frame-pointer
> -flto -ffat-lto-objects -fwhole-program  -o fc-solve  main.o -rdynamic
> libfcs.a -pg -lc_p -lm_p -static-libgcc
> /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in
> `/usr/lib/gcc/x86_64-mageia-linux-gnu/5.4.0/../../../../lib64/libc_p.
> a(strcmp.op)' can not be used when making an executable; recompile with
> -fPIE and relink with -pie
> collect2: error: ld returned 1 exit status
> ../source/Makefile.gnu:243: recipe for target 'fc-solve' failed
> make: *** [fc-solve] Error 1
> shlomif[fcs]:$trunk/fc-solve/profile-b$ git dh
> diff --git a/fc-solve/source/Makefile.gnu b/fc-solve/source/Makefile.gnu
> index 745955e..e238921 100644
> --- a/fc-solve/source/Makefile.gnu
> +++ b/fc-solve/source/Makefile.gnu
> @@ -1,5 +1,5 @@
> -DEBUG = 0
> -PROFILE = 0
> +DEBUG = 1
> +PROFILE = 1
>  WITH_TRACES = 0
>  FREECELL_ONLY = 1
>  DISABLE_PATSOLVE = 1
> @@ -142,8 +142,8 @@ ifneq ($(PROFILE),0)
>                 END_LFLAGS := -lm -lprofiler
>         else
>                 END_OFLAGS := -pg
> -               # END_LFLAGS := -pg -lc_p -lm_p -static-libgcc
> -               END_LFLAGS := -pg -lm
> +               END_LFLAGS := -pg -lc_p -lm_p -static-libgcc
> +               # END_LFLAGS := -pg -lm
>         endif
>  endif
>  
> shlomif[fcs]:$trunk/fc-solve/profile-b$

Hi all!

I should note that when trying to reproduce the problem on my Debian Stretch VM, I realised that -lc_p was not available there and ended up finding these resources:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760450

* http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.23-0ubuntu3/changelog

apprently â* Remove libc6-prof package as it's broken for years and there are better ways to profile code nowadays. Closes: #760450.â. Should we follow suit?

another note is that now:

shlomif@telaviv1:~/progs/C/snippets/shlomif-c-snippets$ gcc -fPIE hello_world.c -lc_p -pie
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/5.4.0/../../../../lib64/libc_p.a(libc-start.op): relocation R_X86_64_32 against `_dl_starting_up' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-mageia-linux-gnu/5.4.0/../../../../lib64/libc_p.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status