GMP 6.1.0 without assembly lacks ‘__gmpn_invert_lib’ on ARM

GMP 6.1.0 without assembly lacks ‘__gmpn_invert_lib’ on ARM

[Ludovic Courtès]

Hello!

When GMP 6.1.0 is built with --host=none-unknown-linux-gnueabihf on
ARMv7 (the way GCC configures its in-tree GMP, as of GCC 4.9.3),
‘__gmpn_invert_lib’ is missing from the resulting libgmp.a.

--8<---------------cut here---------------start------------->8---
$ nm /gnu/store/v6ipb4br8h6sy9zc82aj464cjcgnv7gl-gmp-6.1.0/lib/libgmp.a |grep __gmpn_invert_limb
nm: mp_clz_tab.o: no symbols
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
         U __gmpn_invert_limb
00000000 T __gmpn_invert_limb
nm: repl-vsnprintf.o: no symbols
--8<---------------cut here---------------end--------------->8---

This seems to be expected, but then it looks as though <gmp-impl.h> was
erroneously referring to it, leading to undefined references, as
reported at <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728>.

Ideas?

Thanks,
Ludo’.

Re: GMP 6.1.0 without assembly lacks ‘__gmpn_invert_lib’ on ARM

[Torbjörn Granlund]

ludo@gnu.org (Ludovic Courtès) writes:

  When GMP 6.1.0 is built with --host=none-unknown-linux-gnueabihf on
  ARMv7 (the way GCC configures its in-tree GMP, as of GCC 4.9.3),
  ‘__gmpn_invert_lib’ is missing from the resulting libgmp.a.
  
  --8<---------------cut here---------------start------------->8---
  $ nm /gnu/store/v6ipb4br8h6sy9zc82aj464cjcgnv7gl-gmp-6.1.0/lib/libgmp.a |grep __gmpn_invert_limb
  nm: mp_clz_tab.o: no symbols
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
           U __gmpn_invert_limb
  00000000 T __gmpn_invert_limb
  nm: repl-vsnprintf.o: no symbols
  --8<---------------cut here---------------end--------------->8---
  
  This seems to be expected, but then it looks as though <gmp-impl.h> was
  erroneously referring to it, leading to undefined references, as
  reported at <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728>.
  
I've tried to reproduce this on two different ARM systems, and failed.

I cannot reproduce any link errors, nor can I find the reference or
definitions of the symbol __gmpn_invert_limb.

It also puzzles me that you would get link errors given that
__gmpn_invert_limb is defined in your libgmp.a.

Note also that using "none" as CPU is deprecated and outputs a warning.

Many strange things indeed.

-- 
Torbjörn
Please encrypt, key id 0xC8601622

Re: GMP 6.1.0 without assembly lacks ‘__gmpn_invert_lib’ on ARM

[Ludovic Courtès]

tg@gmplib.org (Torbjörn Granlund) skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>   When GMP 6.1.0 is built with --host=none-unknown-linux-gnueabihf on
>   ARMv7 (the way GCC configures its in-tree GMP, as of GCC 4.9.3),
>   ‘__gmpn_invert_lib’ is missing from the resulting libgmp.a.

[...]

>   This seems to be expected, but then it looks as though <gmp-impl.h> was
>   erroneously referring to it, leading to undefined references, as
>   reported at <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728>.
>   
> I've tried to reproduce this on two different ARM systems, and failed.
>
> I cannot reproduce any link errors, nor can I find the reference or
> definitions of the symbol __gmpn_invert_limb.

The undefined references come up when linking for instance GCC against
GMP:

--8<---------------cut here---------------start------------->8---
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/./gmp/.libs/libgmp.a(powm_ui.o): In function `__gmpz_powm_ui':
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/gmp/mpz/../../../gcc-4.9.3/gmp/mpz/powm_ui.c:162: undefined reference to `__gmpn_invert_limb'
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/./gmp/.libs/libgmp.a(divrem_1.o): In function `__gmpn_divrem_1':
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/gmp/mpn/divrem_1.c:149: undefined reference to `__gmpn_invert_limb'
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/gmp/mpn/divrem_1.c:228: undefined reference to `__gmpn_invert_limb'
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/./gmp/.libs/libgmp.a(divrem_2.o): In function `__gmpn_divrem_2':
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/gmp/mpn/divrem_2.c:91: undefined reference to `__gmpn_invert_limb'
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/./gmp/.libs/libgmp.a(lt86-sqrtrem.o): In function `mpn_divappr_q':
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/gmp/mpn/sqrtrem.c:280: undefined reference to `__gmpn_invert_limb'
/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/./gmp/.libs/libgmp.a(div_q.o):/tmp/nix-build-gcc-cross-boot0-4.9.3.drv-0/build/gmp/mpn/div_q.c:251: more undefined references to `__gmpn_invert_limb' follow
collect2: error: ld returned 1 exit status
--8<---------------cut here---------------end--------------->8---

See <http://hydra.gnu.org/build/865660/nixlog/1/raw> for a complete log.

> It also puzzles me that you would get link errors given that
> __gmpn_invert_limb is defined in your libgmp.a.

Sorry, I pasted the “wrong” one.  Here’s what I have for a no-asm build:

--8<---------------cut here---------------start------------->8---
$ nm /gnu/store/924bg8ws2fkk4z0bifzkqg5d57pgc4w1-gmp-6.1.0/lib/libgmp.a|grep invert_limb
00000000 R __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
         U __gmp_binvert_limb_table
nm: repl-vsnprintf.o: no symbols
--8<---------------cut here---------------end--------------->8---

> Note also that using "none" as CPU is deprecated and outputs a warning.

I know, but this is what GCC uses (which makes sense, because it
also supports older versions of GMP.)

I hope this clarifies things.

Thanks,
Ludo’.

Re: GMP 6.1.0 without assembly lacks ‘__gmpn_invert_lib’ on ARM

[Torbjörn Granlund]

ludo@gnu.org (Ludovic Courtès) writes:

  The undefined references come up when linking for instance GCC against
  GMP:
  
  .../build/./gmp/.libs/libgmp.a(powm_ui.o): In function `__gmpz_powm_ui':
  .../build/gmp/mpz/../../../gcc-4.9.3/gmp/mpz/powm_ui.c:162: undefined reference to `__gmpn_invert_limb'
  
  > It also puzzles me that you would get link errors given that
  > __gmpn_invert_limb is defined in your libgmp.a.
  
  Sorry, I pasted the “wrong” one.  Here’s what I have for a no-asm build:
  
Ok, but these are both __gmpn_invert_limb.

  $ nm /gnu/store/924bg8ws2fkk4z0bifzkqg5d57pgc4w1-gmp-6.1.0/lib/libgmp.a|grep invert_limb
  00000000 R __gmp_binvert_limb_table
           U __gmp_binvert_limb_table
           U __gmp_binvert_limb_table
           U __gmp_binvert_limb_table
           U __gmp_binvert_limb_table
  
OK, so here we have a different defined and referenced symbol.  In what
way is that relevant for the linker error above?

  I hope this clarifies things.
  
Unfortunately, no.

This is wasting everyone's time.  Here is how:

http://lmgtfy.com/?q=gmp+reporting+bugs

-- 
Torbjörn
Please encrypt, key id 0xC8601622

Re: GMP 6.1.0 without assembly lacks ‘__gmpn_invert_lib’ on ARM

[Christopher Allan Webber]

Torbjörn Granlund writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>   I hope this clarifies things.
>   
> Unfortunately, no.
>
> This is wasting everyone's time.  Here is how:
>
> http://lmgtfy.com/?q=gmp+reporting+bugs

This was a very rude response.  Please don't respond like this on the
list again.

Guix has traditionally been a very friendly environment.  I know many of
us would like to keep it that way.  Being dismissive of someone who is
really trying to help is not nice, and disincentivizes them from helping
you.  You may be underestimating how much this kind of response can hurt
someone.

Let's please be nice to each other.

 - Chris

On being welcoming

[Ludovic Courtès]

Torbjörn,

I dare say that technical expertise does not excuse disdain and
contempt.  This behavior is actively harmful to GMP and GNU.  It also
illustrates why codes of conduct are more than a cosmetic gimmick.

I hope some of your peers will recognize the issue and step up to say
that this is not acceptable.

Happy hacking,
Ludo’.

Re: On being welcoming

[Mike Mohr]

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

Based on my reading of the gmp-bugs mailing list over the past several
years as well as the source code to various GMP releases, it is abundantly
clear to me that Torbjörn is a highly talented individual and that the the
GMP library would not be what it is today without him.

However, I must concur with Ludovic in this matter.  I have seen many
examples of this type of conduct from him, both towards myself as well as
others.  I am a software engineer who works in Silicon Valley, and I cannot
imagine working with someone who is frequently abrasive and disparaging.
Such an individual would not last very long on my team.  I am well aware of
the stress involved with writing and maintaining a complex piece of
software, as well as working with people who are less technically competent
than I am, but that doesn't give me carte blanche to be hostile towards
them.

The tone of this community is determined in large part by its core
developers.  Niels Möller, for example, is consistently a great example of
a positive, constructive team member.

"As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance."

Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6,
page 163). Carbondale, IL: Southern Illinois University Press.

On Thu, Dec 17, 2015 at 1:48 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> Torbjörn,
>
> I dare say that technical expertise does not excuse disdain and
> contempt.  This behavior is actively harmful to GMP and GNU.  It also
> illustrates why codes of conduct are more than a cosmetic gimmick.
>
> I hope some of your peers will recognize the issue and step up to say
> that this is not acceptable.
>
> Happy hacking,
> Ludo’.
> _______________________________________________
> gmp-bugs mailing list
> gmp-bugs@gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-bugs
>

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

Re: On being welcoming

[Niels Möller]

ludo@gnu.org (Ludovic Courtès) writes:

> I dare say that technical expertise does not excuse disdain and
> contempt.  This behavior is actively harmful to GMP and GNU.

Some developers may be more polite than others, but you really need to
follow the bug reporting instructions. If it is a bug in gmp, we'd like
to fix it, of course. Or if it's a configuration error, we'd like to
resolve that too, but then we still need to start with the proper bug
reporting information.

> It also illustrates why codes of conduct are more than a cosmetic
> gimmick.

I'd prefer not to not have the general code-of-conduct-debate on the
gmp-bugs list.

If you are disappointed about any individual's behaviour, I suspect it's
usually more productive to start by trying to solve it off list (maybe
you did? I wouldn't know of course). Mailing list discussons about
personal issues tend to overheat too easily.

(And it has taken me more than 30 minutes to formulate this reply, which
I hope is sufficiently polite and respectful. I really hope that was time
well spent).

Best regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

Re: On being welcoming

[Ludovic Courtès]

nisse@lysator.liu.se (Niels Möller) skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> I dare say that technical expertise does not excuse disdain and
>> contempt.  This behavior is actively harmful to GMP and GNU.
>
> Some developers may be more polite than others, but you really need to
> follow the bug reporting instructions.

Of course I need to follow them.  The crucial thing is that this can be
said in a respectful way, like you did.  No need to be insulting.

> If you are disappointed about any individual's behaviour, I suspect it's
> usually more productive to start by trying to solve it off list (maybe
> you did? I wouldn't know of course). Mailing list discussons about
> personal issues tend to overheat too easily.

This is not a personal issue at all.  This behavior is a problem not
just for me (it wouldn’t matter, I could just refrain from ever
contributing).  It is a problem for the project.

I think it is crucially important that you as a community recognize that
this behavior is not acceptable.  There’s nothing personal in doing
that; it’s the behavior that we should condemn, not the person.

It would be a missed opportunity if, once again, this behavior is
quietly excused.

Thank you Niels for having taken the time to reply.

Ludo’.

Re: On being welcoming

[Niels Möller]

ludo@gnu.org (Ludovic Courtès) writes:

> It would be a missed opportunity if, once again, this behavior is
> quietly excused.

If you are offended on a mailing list, or you see someone else being
offended, I strongly recommend that you start with a *private*
complaint, hoping for a *public* apology. 

That reduces the risk that the apology either drowns in an inproductive
flame fest, or becomes impossible due to personal prestige invested in a
public debate.

Only if the private approach doesn't work out, consider escalating the
issue.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

Re: On being welcoming

[Niels Möller]

Mike Mohr <akihana@gmail.com> writes:

> I am a software engineer who works in Silicon Valley, and I cannot
> imagine working with someone who is frequently abrasive and disparaging.
> Such an individual would not last very long on my team.

I think it's a grand mistake to compare the social workings of a spare
time project with the relations within a professional development team.
In silicon valley or elsewhere.

I can only speak for myself, but I have pretty limited hacking time for
my spare-time projects. And when I get some quality time when I'm at my
best, and able to de some real hacking, I prefer doing the hacking.

Which means that responding on mailing lists is more often than not done
when I'm tired and likely to be more grumpy and less alert than usual.

At my day job, conditions are quite different. Email to my collegues can
usually get all care and attention they really need, and furthermore,
I'm usually not supporting end users.

(And discussions like these are also distractions from hacking, but
sure, they are sometimes necessary too).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

Re: On being welcoming

[Christopher Allan Webber]

Niels Möller writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> I dare say that technical expertise does not excuse disdain and
>> contempt.  This behavior is actively harmful to GMP and GNU.
>
> Some developers may be more polite than others, but you really need to
> follow the bug reporting instructions. If it is a bug in gmp, we'd like
> to fix it, of course. Or if it's a configuration error, we'd like to
> resolve that too, but then we still need to start with the proper bug
> reporting information.

Certainly that's true, though of course a "please file this upstream in
GMP, we'd really like to handle it there" would be a nice way to handle
things.  And of course hashing out what's happening locally is not
unusual behavior; Debian does much work to determine whether a bug is a
Debian-local issue or if it is an upstream issue, and if so (hopefully)
file and resolve upstream.  It is not always a perfect process, but Guix
is also a distribution, and it's unsurprising that some conversation
would likely happen here first.

I doubt that Ludovic would have been opposed to filing upstream if the
upstream developers encouraged that... I don't think that was the issue
here.

>> It also illustrates why codes of conduct are more than a cosmetic
>> gimmick.
>
> I'd prefer not to not have the general code-of-conduct-debate on the
> gmp-bugs list.

Sure, though this conversation was on the Guix list.

> If you are disappointed about any individual's behaviour, I suspect it's
> usually more productive to start by trying to solve it off list (maybe
> you did? I wouldn't know of course). Mailing list discussons about
> personal issues tend to overheat too easily.

Sometimes that's true, and I agree, contacting an individual off-list is
usually the first line to handle, especially for smaller issues.  In
general, I think this is the best approach to get good community
interaction.  I don't know if it happened or not.

Though sometimes it is good to give a reply on-list, even in the first
instance, so that it can be clear to a community what behavior is and
isn't okay.

> (And it has taken me more than 30 minutes to formulate this reply, which
> I hope is sufficiently polite and respectful. I really hope that was time
> well spent).

I thought it was very polite and respectful, thank you!

 - Chris

> Best regards,
> /Niels

Re: On being welcoming

[Torbjörn Granlund]

[To gmp-discuss readers: This started at gmp-bugs, first as a couple of
reports about assumed GMP bugs, then with the subject used here.]

ludo@gnu.org (Ludovic Courtès) writes:

  I think it is crucially important that you as a community recognize that
  this behavior is not acceptable.  There’s nothing personal in doing
  that; it’s the behavior that we should condemn, not the person.
  
Let's not exaggerate; sending sloppy bug reports might be considered as
disrespectful, but I wouldn't go so far as calling "this behavior"
"unacceptable".  We're making a mistake if we assume malice when we read
something we do not like.

Mike Mohr <akihana@gmail.com> writes:

  I have seen many examples of this type of conduct from him, both
  towards myself as well as others.  I am a software engineer who
  works in Silicon Valley, and I cannot imagine working with someone
  who is frequently abrasive and disparaging.  Such an individual
  would not last very long on my team.

We're all humans and I shall not exaggerate my critisism of sloppy bug
reports, and I shall not sink to making an ad hominem response.

[I'm going back to doing productive work now. I will not respond further
to this thread, but I respect that others might want to continue, and I
will read the contributions.  Please use gmp-discuss, the gmp-bugs list
is for bug reports.]

-- 
Torbjörn
Please encrypt, key id 0xC8601622

Re: On being welcoming

[Christopher Allan Webber]

Niels Möller writes:

> Mike Mohr <akihana@gmail.com> writes:
>
>> I am a software engineer who works in Silicon Valley, and I cannot
>> imagine working with someone who is frequently abrasive and disparaging.
>> Such an individual would not last very long on my team.
>
> I think it's a grand mistake to compare the social workings of a spare
> time project with the relations within a professional development team.
> In silicon valley or elsewhere.
>
> I can only speak for myself, but I have pretty limited hacking time for
> my spare-time projects. And when I get some quality time when I'm at my
> best, and able to de some real hacking, I prefer doing the hacking.
>
> Which means that responding on mailing lists is more often than not done
> when I'm tired and likely to be more grumpy and less alert than usual.

This is the last reply I will give on this thread, but I think that it's
important.

One of the issues is that emails which are rude or impolite can really
drain participants.  And of course, not just one person, but many people
on a list can really be drained by reading these kinds of things.  Some
people might be afraid to join.

I know when there's a really negative exchange, it takes it out of me.
And that means it reduces my time I'm able to spend hacking and doing
positive contributions that I would like to.

So yes, let's all recognize our limited time and abilities to
participate.  One way we can be especially respectful and do a good job
of showing such recognition is to be careful to be nice to each other on
lists.

The net effect of "spare time productivity" will likely be higher,
because people will lose less energy to feeling drained by negative
exchanges.

So, in the long run, I do think it's worth that extra time to be
thoughtful... not being rude does not take very much extra energy,
and in the long run, leads to higher productive energy!

 - Chris

Re: GMP 6.1.0 without assembly lacks ‘__gmpn_invert_lib’ on ARM

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> When GMP 6.1.0 is built with --host=none-unknown-linux-gnueabihf on
> ARMv7 (the way GCC configures its in-tree GMP, as of GCC 4.9.3),
> ‘__gmpn_invert_lib’ is missing from the resulting libgmp.a.

For the record I worked around it in 8309c38 (‘core-updates’).

Ludo’.

Re: On being welcoming

[Mike Mohr]

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

(Replies inline.)

On Fri, Dec 18, 2015 at 11:04 AM, Torbjörn Granlund <tg@gmplib.org> wrote:

> [To gmp-discuss readers: This started at gmp-bugs, first as a couple of
> reports about assumed GMP bugs, then with the subject used here.]
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
>   I think it is crucially important that you as a community recognize that
>   this behavior is not acceptable.  There’s nothing personal in doing
>   that; it’s the behavior that we should condemn, not the person.
>
> Let's not exaggerate; sending sloppy bug reports might be considered as
> disrespectful, but I wouldn't go so far as calling "this behavior"
> "unacceptable".  We're making a mistake if we assume malice when we read
> something we do not like.
>

To an outsider, who is perhaps unfamiliar with common software development
practices, sloppy bug reports are easy mistakes to make.  I doubt that the
reporter had any ill intent.


>
> Mike Mohr <akihana@gmail.com> writes:
>
>   I have seen many examples of this type of conduct from him, both
>   towards myself as well as others.  I am a software engineer who
>   works in Silicon Valley, and I cannot imagine working with someone
>   who is frequently abrasive and disparaging.  Such an individual
>   would not last very long on my team.
>
> We're all humans and I shall not exaggerate my critisism of sloppy bug
> reports, and I shall not sink to making an ad hominem response.
>
> [I'm going back to doing productive work now. I will not respond further
> to this thread, but I respect that others might want to continue, and I
> will read the contributions.  Please use gmp-discuss, the gmp-bugs list
> is for bug reports.]
>

Torbjörn, I sincerely apologize if my initial response was interpreted as
an ad hominem attack.  It was certainly not intended as such.  I actually
spent a good amount of time weighing whether I should respond at all,
followed by writing and rewriting several parts of the response.  The
initial paragraph, where I mention how valuable your contributions are to
the GMP project, is missing from your inline response.  The second
paragraph seems harsher than I intended when read out of context.

Your response to the original bug report was accurate; there was
insufficient information in it.  I am very aware of how frustrating
incomplete bug reports can be, especially when working on a project for
free in your spare time.  My only intent was to share constructive
criticism regarding how you responded to the reporter.


>
> --
> Torbjörn
> Please encrypt, key id 0xC8601622
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss@gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-discuss
>

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