gcc46, gcc47 @4.7.2 'init_priority' attribute is not supported on this platform

[ilg@…]

According to the GCC manuals, the

 __attribute__ ((init_priority (NNN)))

should be supported by classes and

 __attribute__((constructor(NNN))) 

by functions.

​http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes

Unfortunately the current version fails to compile programs using this attributes:

OS.cpp:16:57: error: constructor priorities are not supported
OS.cpp:35:59: error: 'init_priority' attribute is not supported on this platform

Regards,

Liviu

[ilg@…]

The same problem applies to the gcc46 port.

Liviu

[ryandesign (Ryan Carsten Schmidt)]

What should the MacPorts project do to correct this problem?

[jeremyhu (Jeremy Huddleston Sequoia)]

This is an upstream issue.

[ilg@…]

Replying to jeremyhu@…:

This is an upstream issue.

What do you mean by that?

I just performed a test and the default compiler in Ubuntu is quite happy with both

__attribute__((constructor(101)));
__attribute__((init_priority(102)));

The same applies to various cross compilers I used in the past, and lately, to the default clang++ that comes with Xcode.

My guess is that you either missed some build options, or you forgot to apply a mandatory patch.

I suggest you check the build procedure used for the Ubuntu gcc4.7 and update the MacPorts one accordingly.

Regards,

Liviu

[jmroot (Joshua Root)]

You realise the error message says "on this platform" and Ubuntu is a different platform, right?

Seriously, we can't fix this.

​http://gcc.gnu.org/viewcvs/tags/gcc_4_7_2_release/gcc/config/darwin.h?revision=191558&view=markup

/* The Apple assembler and linker do not support constructor priorities.  */
#undef SUPPORTS_INIT_PRIORITY
#define SUPPORTS_INIT_PRIORITY 0

[cooljeanius (Eric Gallager)]

Replying to ilg@…:

Replying to jeremyhu@…:

This is an upstream issue.

What do you mean by that?

It means that it's an issue for the GCC developers, not the MacPorts developers.

[larryv (Lawrence Velázquez)]

wontfix implies that this is our problem.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to egall@…:

Replying to ilg@…:

Replying to jeremyhu@…:

This is an upstream issue.

What do you mean by that?

It means that it's an issue for the GCC developers, not the MacPorts developers.

Actually, gcc developers are blocked by insufficient support on the host because OS X's dyld doesn't support this at runtime.

For anyone at Apple following up on this, see <rdar://problem/13028730>.

[cooljeanius (Eric Gallager)]

Replying to jeremyhu@…:

Replying to egall@…:

Replying to ilg@…:

Replying to jeremyhu@…:

This is an upstream issue.

What do you mean by that?

It means that it's an issue for the GCC developers, not the MacPorts developers.

Actually, gcc developers are blocked by insufficient support on the host because OS X's dyld doesn't support this at runtime.

For anyone at Apple following up on this, see <rdar://problem/13028730>.

​OpenRadar issue link for the rest of us?

[ilg@…]

Actually, gcc developers are blocked by insufficient support on the host because OS X's dyld doesn't support this at runtime.

Really? Oops, then I just completed an impossible task :-)

My opinion is that the above statement about OS X not supporting init priorities is a thing of the past, as long as programs compiled with native clang accept it without problems, proper support should already be present since the move to llvm/clang.

To prove this I patched gcc/config/darwin.h and changed

#define SUPPORTS_INIT_PRIORITY 1

Then I successfully built the stock 4.7.2 using clang:

export CC=clang
export CXX=clang++
./configure ...
make
...

Could you update the existing Portfile to apply this simple patch and to use clang/clang++ during build? (it might not be necessary to explicitly use clang, I don't know now, but I can find out in about one hour)

Liviu

[ilg@…]

Replying to ilg@…:

(it might not be necessary to explicitly use clang, I don't know now, but I can find out in about one hour)

I confirm it, the init_priority() and constructor() attributes are functional even without explicitly compiling with clang, just patch the prehistoric darwin.h and the rest is done by the system.

As of now I did it only for 4.7, but I expect 4.6 to work as well.

Liviu

[jeremyhu (Jeremy Huddleston Sequoia)]

If you did that, you have a broken toolchain. The runtime doesn't support it.

[ilg@…]

Replying to jeremyhu@…:

... The runtime doesn't support it.

further extensive tests showed that you are partly right, although the compiler reorders correctly the constructors within a compilation unit, the OS X linker ignores the init_priority() attribute and does not reorder the constructors (the constructors are called in the same order as the objects are linked).

thank you for your patience,

Liviu