[omniORB] Ordering of #pragma hh relative to USE_core_stub_in_nt_dll_NOT_DEFINED_*

[Andrew Miller]

Hi,

I have noticed that when pragma hh is used (e.g. as in COS), it comes
after the NOT_DEFINED_* defines...

#ifndef USE_core_stub_in_nt_dll
# define USE_core_stub_in_nt_dll_NOT_DEFINED_CosEventComm
#endif
#ifndef USE_dyn_stub_in_nt_dll
# define USE_dyn_stub_in_nt_dll_NOT_DEFINED_CosEventComm
#endif


#include "COS_sysdep.h"

(I had to apply the patch which fixes pragmas from CVS to get a standard
4.0.7 tree to even get that far).

Because USE_core_stub_in_nt_dll only gets defined by the pragma hh
output after the NOT_DEFINED_* macro is set, it doesn't get cleared at
the end of the header, and so all the data symbols in the including
header end up getting imported too, even if they should be exported
rather than imported.

I can submit a patch to reverse this order, but given that it presumably
works for everyone else, perhaps I am missing something? I am trying to
follow the instructions in case 4 listed in 12.2.2 of the omniORB manual
(the version generated in omniORB-4.0.7/doc/omniORB.pdf).

Thanks and Best regards,
Andrew Miller

[Andrew Miller]

Post by Andrew Miller
Hi,
I have noticed that when pragma hh is used (e.g. as in COS), it comes
after the NOT_DEFINED_* defines...
#ifndef USE_core_stub_in_nt_dll
# define USE_core_stub_in_nt_dll_NOT_DEFINED_CosEventComm
#endif
#ifndef USE_dyn_stub_in_nt_dll
# define USE_dyn_stub_in_nt_dll_NOT_DEFINED_CosEventComm
#endif
#include "COS_sysdep.h"

On further thought, the ordering is correct, because the point of those
defines is to save the state from the previous header.

The problem is that if you define USE_stub_in_nt_dll (as the manual
suggests), rather than USE_core_stub_in_nt_dll and
USE_dyn_stub_in_nt_dll, it never gets reversed. This doesn't affect COS,
because it explicitly defines USE_dyn_stub_in_nt_dll and
USE_core_stub_in_nt_dll.

This could be fixed either by updating the documentation, or by adding
similar code for USE_stub_in_nt_dll as for the other defines into
template.py.

Best regards,
Andrew Miller

[Duncan Grisby]

On Friday 22 September, Andrew Miller wrote:

[...]

Post by Andrew Miller
The problem is that if you define USE_stub_in_nt_dll (as the manual
suggests), rather than USE_core_stub_in_nt_dll and
USE_dyn_stub_in_nt_dll, it never gets reversed. This doesn't affect
COS, because it explicitly defines USE_dyn_stub_in_nt_dll and
USE_core_stub_in_nt_dll.
This could be fixed either by updating the documentation, or by adding
similar code for USE_stub_in_nt_dll as for the other defines into
template.py.

Thanks for pointing that out. I've fixed it in the 4.1 tree by
undefining USE_stub_in_nt_dll at the end of the header if it was not set
at the start, as with the other macros.

Cheers,

Duncan.