On Apr 9, 2013, at 2:35 PM, Niels Möller wrote:

Perry Smith pedzsan@gmail.com writes:

...

Editing the configure.ac is fine. But I had to change the make rules so the shared library depended upon nettle_OBJS instead of nettle_PURE_OBJS. I *think* (but I'm not sure) that the .po suffix confuses the linker. It appears as if it was just ignoring all the .po files.

Maybe that suffix was poorly choosen.

...

I've never seen "pure" objects before. Is this really a useful concept?

The idea is that objects that go into a shared library should be compiled as position independent code (so that the code pages really can be shared, with no relocations depending on the address at which they are mapped), while objects that go into a static library usually should not (except for the --enable-pic / --disable-pic options, see below). So foo.c is compiled to foo.o and to foo.po, with different compiler flags.

To make things work on AIX, I guess we need to do one or more of

• Replace the .po suffix by .p.o or _p.o, which should make it more

obvious to various tools that they really are object files.

• Patch configure with whatever is needed to actually compile position

independent code on AIX (I hope the current defaults should work if you build with gcc, but most likely they won't work at all with the system compiler).

• Add some configure option (or use --disable-pic) to not try to compile

anything as position independent code.

About the --enable-pic / --disable-pic configure options, I'm not sure if they currently work as intended. --enable-pic was introduced a long time ago to make also the objects for the static library compiled as position independent code, which was useful if you built some plugin.so intended to be loaded dynamically into some application, and that plugin.so was linked statically with nettle. And it seems that currently, --enable-pic is the default.

So I'm not sure, is it still useful to use non-pic code for the static library, or can we drop support for that, always using position-independent code whenever the configure script can figure out how to do it?

Also, I think the current use of CCPIC_MAYBE is a bit ugly. In the (currently default) case that the static libnettle.a library uses position independent code, it would be better to simply have it depend on the .po files, and not build the "regular" .o files at all.

It would be interesting to see what platforms need the non-pic mode. I've not heard of anything other than position independent code for a fairly long time now.

The default output of IBM's xlc compiler as well as GNU's gcc compiler is to produce position independent code for AIX. I believe that is true for any Power PC platform. And I thought that that was true for almost any modern chip (Intel, etc).

I fear that I don't know enough about the history of the code to help much. The only very general comment I have is the other open source projects that I compile (for Mac and AIX) almost all create a shared library and they do it with what appears to be normal calls to GCC.

Hope this helps... Perry

On Apr 10, 2013, at 2:07 AM, Niels Möller wrote:

Perry Smith pedzsan@gmail.com writes:

...

It would be interesting to see what platforms need the non-pic mode. I've not heard of anything other than position independent code for a fairly long time now.

I think it matters in two ways.

1. On processors that lack general pc-relative addressing, e.g., x86_32,

pic code causes additonal overhead when, e.g., addressing constant data tables. I think there are some issues on x86_64 darwin as well, but I guess that's just problems with Apple's tools, nothing fundamental.

2. Constant data structures which contain absolute pointers, like

nettle's

const struct nettle_cipher nettle_aes128;

If you do position independent code, the pointers have to be relocated at load time, so the structure has to be allocated in the data segment (despite "const"). If we allow position dependent code, the structure can be put into the rodata segment where one might expect it, with relocation done only at link time.

...

The default output of IBM's xlc compiler as well as GNU's gcc compiler is to produce position independent code for AIX. I believe that is true for any Power PC platform. And I thought that that was true for almost any modern chip (Intel, etc).

Ok, so on those platforms we shouldn't pass any special flags for compilation. I guess we still need some xlc-specific options if we use xlc for *linking* the shared library?

Ok. I looked at the gcc manual about -fPIC. I'm surprised. I thought hardware had evolved more.

In any case, it did confirm: "Code generated for the IBM RS/6000 is always position-independent." (This is true for both compilers.) Also, just to be clear, I'm using GCC.

The suggestion I had was to have SUFFIX (like you have) and PIC_SUFFIX. For the RS/6000 and Power PC, PIC_SUFFIX could be .o so it would not recompile all the code a second time.

The other idea I had is to have a .pic directory and put the PIC objects in that directory with a normal .o suffix.

Perry