Building Mozilla LDAP SDK

[Steve_The_King]

I am trying to build mozilla LDAP SDK on hp-ux 11.11. I am getting the following errors:
gmake[2]: Entering directory `/scratch/kavita/LDAP_SDK5_Source/mozilla/security/coreconf/nsinstall'
cc -o HP-UXB.11.11_OPT.OBJ/nsinstall.o -c -O -DHPUX10 -D_POSIX_C_SOURCE=199506L -Ae +Z -DHPUX -Dhppa -D_HPUX_SOURCE -DHPUX11 -DXP_UNIX -UDEBUG -DNDEBUG -I../../../dist/HP-UXB.11.11_OPT.OBJ/include -I../../../dist/public/coreconf -I../../../dist/private/coreconf nsinstall.c
(Bundled) cc: warning 480: The -O option is available only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored.
(Bundled) cc: "pathsub.h", line 60: error 1705: Function prototypes are an ANSI feature.
(Bundled) cc: "pathsub.h", line 61: error 1705: Function prototypes are an ANSI feature.
(Bundled) cc: "pathsub.h", line 62: error 1000: Unexpected symbol: "ino".
(Bundled) cc: "pathsub.h", line 62: error 1705: Function prototypes are an ANSI feature.
(Bundled) cc: "pathsub.h", line 63: error 1000: Unexpected symbol: "size".
(Bundled) cc: "pathsub.h", line 63: error 1506: Parameters allowed in function definition only.
(Bundled) cc: "pathsub.h", line 64: error 1705: Function prototypes are an ANSI feature.
(Bundled) cc: "pathsub.h", line 65: error 1705: Function prototypes are an ANSI feature.
(Bundled) cc: "pathsub.h", line 66: error 1705: Function prototypes are an ANSI feature.
(Bundled) cc: "pathsub.h", line 69: error 1705: Function prototypes are an ANSI feature.
(Bundled) cc: "pathsub.h", line 72: error 1705: Function prototypes are an ANSI feature.
(Bundled) cc: "pathsub.h", line 75: warning 5: "const" will become a keyword.
(Bundled) cc: "pathsub.h", line 75: error 1000: Unexpected symbol: "char".
(Bundled) cc: error 2017: Cannot recover from earlier errors, terminating.
gmake[2]: *** [HP-UXB.11.11_OPT.OBJ/nsinstall.o] Error 1


Can anybody help ?

[James R. Ferguson]

Hi:

You need the Ansi C compiler. You have only the bundled C one which is virtually useless. You can license a version here:

http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B9007AA

An evaluation copy is also available here:

http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B9007AAEVAL

Regards!

...JRF...

[Steve_The_King]

I tried accessing the link provided for evaluation copy of cc compiler but the instaaltion instructions say that we need to have a 26-digit hexadecimal license key. I did not find this key anywhere. Please help.

[James R. Ferguson]

Hi (again):

See:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1048444

Regards!

...JRF...

[Steve_The_King]

I encounterd the following problem while building mozilla ldap sdk. Can someone please let me know how to go about it ?

cc: "/scratch//LDAP_SDK5_Source/mozilla/nsprpub/pr/include/prlock.h", line 80: warning 870: __declspec() ignored if -Bhidden/-Bhidden_def not used.
cc: "/scratch//LDAP_SDK5_Source/mozilla/nsprpub/pr/include/prlock.h", line 91: error 1000: Unexpected symbol: "export".
cc: "/scratch//LDAP_SDK5_Source/mozilla/nsprpub/pr/include/prlock.h", line 91: warning 870: __declspec() ignored if -Bhidden/-Bhidden_def not used.
cc: "/scratch//LDAP_SDK5_Source/mozilla/nsprpub/pr/include/prlock.h", line 102: error 1000: Unexpected symbol: "export".
cc: "/scratch//LDAP_SDK5_Source/mozilla/nsprpub/pr/include/prlock.h", line 102: warning 870: __declspec() ignored if -Bhidden/-Bhidden_def not used.

[Dennis Handly]

>I encountered the following problem while building mozilla ldap sdk.
cc: ".../include/prlock.h", line 91: error 1000: Unexpected symbol: "export".

You need to provide what was on line 91. There also may be evil macros that change what you see in your .h. So you need to compile with -E and save stdout. Then see if you can find that same line and see where export comes from.

If it still isn't obvious, you need a bigger gun:
cc ... -E -Wp,-C,-G
Then save stdout and look for export.

[Steve_The_King]

Line 91 conatins
NSPR_API(void) PR_DestroyLock(PRLock *lock);

Also I am getting the same problem for other files.For eg
/scratch/LDAP_SDK5_Source/mozilla/nsprpub/pr/include/pratom.h
line 57: error 1000: Unexpected symbol: "export"

where line 57 is :-

NSPR_API(PRInt32) PR_AtomicIncrement(PRInt32 *val);



The same error continues for many other files.

[Dennis Handly]

>Line 91 contains:
NSPR_API(void) PR_DestroyLock(PRLock *lock);

Then there must be evil macros on that line. As I said:
If it still isn't obvious, you need a bigger gun: cc ... -E -Wp,-C,-G
Then save stdout and look for export.

[Steve_The_King]

Following is the stdout with -E option and I can see export keyword here.

I am sorry but I din't still din't understand how to solve it. :-(


# 45 "/scratch/LDAP_SDK5_Source/mozilla/nsprpub/pr/include/pratom.h"


# 57
extern __declspec(export) PRInt32 PR_AtomicIncrement(PRInt32 *val);
# 68
extern __declspec(export) PRInt32 PR_AtomicDecrement(PRInt32 *val);
# 80
extern __declspec(export) PRInt32 PR_AtomicSet(PRInt32 *val, PRInt32 newval);
# 92
extern __declspec(export) PRInt32 PR_AtomicAdd(PRInt32 *ptr, PRInt32 val);

[Dennis Handly]

As I said:
If it still isn't obvious, you need a bigger gun: cc ... -E -Wp,-C,-G
Then save stdout and look for export.

With -G, cpp enables an obsolete static analysis for macros. By looking at that line you should see the macro and the macro expansion. Probably NSPR_API.

Your original message had prlock.h but this one has pratom.h?

[Weltman, Ulf]

Which version of the LDAP SDK, NSPR, and NSS are you trying to build?

The free product LDAP-UX Integration delivers a pre-built Mozilla LDAP SDK and its dependencies. It's supported by HP and includes the header files for development. LDAP-UX 4.0 bundles LDAP SDK 5.14.1 and LDAP-UX 4.1x bundles LDAP SDK 5.17.1.
http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=J4269AA

[Steve_The_King]

Below is the output I got after building my code with the above mentioned flags.

I found some ^A and ^C characters. Any Idea what are they ???

^Aextern __declspec(export) PRInt32^BNSPR_API(PRInt32)^C PR_AtomicIncrement(PRInt32 *val);

[James R. Ferguson]

Hi (again):

> I found some ^A and ^C characters. Any Idea what are they ???

The ^A would be a SHO (Start-of-Header) and the ^C would be an ETX (End-of-Text).

You will find the 'ascii(5)' manpages useful.

Regards!

...JRF...

[Steve_The_King]

There are ^C characters at the start of #define statements and also some ^B characters. What do these mean. Again what are 'ascii(5)' manpages. Please let me know.

And how do I now proceed with my compilation.

[James R. Ferguson]

Hi (again):

> There are ^C characters at the start of #define statements and also some ^B characters. What do these mean. Again what are 'ascii(5)' manpages. Please let me know.

The characters should not be present. However you propagated the file to the platform on which you see these characters must have introduced them.

# man 5 ascii

...or:

http://docs.hp.com/en/B2355-60105/ascii.5.html

Regards!

...JRF...

[Dennis Handly]

>I found some ^A and ^C characters. Any idea what are they???
^Aextern __declspec(export) PRInt32^BNSPR_API(PRInt32)^C

These are how the preprocessing static analysis info is passed to the compiler. The text between ^A and ^B is the macro expansion and the text between ^B and ^C is the macro.

So the macro NSPR_API is broken. It should be either:
#define NSPR_API(X) extern __declspec(dllexport) X
or:
#define NSPR_API(X) extern X

>And how do I now proceed with my compilation.

You need to find where NSPR_API is defined and see if there are some -Ds that make it work for HP-UX, or you need to fix it.

>JRF: You will find the 'ascii(5)' manpages useful.
>The characters should not be present.

Not in this case.
Of course they should. Steve did what I wanted. This is how you debug evil macro problems.

[Steve_The_King]

I observered the following thing:-

While building with -Wp, -C, -G flags, if I redirect the output to a file I can see various ^C, ^B flags. But when the output is on standard output it seems fine . No ^C, ^B , ^A are found, so I guess this is fine.


But what next ??????

[Dennis Handly]

>I observed the following thing:
>While building with -Wp, -C, -G flags, if I redirect the output to a file I can see various ^C, ^B flags.

You (or more correctly I) want to see them.

>But what next?

I told you. You need to fix the NSPR_API macro. If you scan that -E output file you'll see where it is defined.

Then you find the .c or .h and look at that.
Of course there could be another macro that changes dllexport to export.

If you attach that -E output file, I can look at it. (You may have to gzip it.)

[Steve_The_King]

here's file.txt with built with the specified macros

[Dennis Handly]

>here's file.txt with built with the specified macros

Searching for NSPR_API shows it is line 202 in .../pr/include/prtypes.h. This macro uses PR_IMPORT.
Line 154 defines PR_IMPORT with the incorrect __declspec(export)

(You can stop right here and just change "export" to "dllexport".)

On line 80 there is:
#elif defined(XP_MAC)
This seems to be false because there are a bunch of skipped lines. 151 has a #else?

Perhaps you have mistakenly defined XP_MAC?
This seems to be defined if not defined in .../pr/src/md/mac/prcpucfg.h on line 36.
So I don't know why XP_MAC seems to be false?
Can you provide ../pr/include/prtypes.h?

[Steve_The_King]

Thanks for your immediate responses.
I am attaching prtypes.h.

I tried building the code changing export to dllexport where we have #defined (XP_MAC) line 150.

The build goes fine but few warnings.
warning : __declspec() ignored if -Bhidden/-Bhidden_def not used.

Is it O.K to build the code by changing export to dllexport or can there be some consequences.

[Dennis Handly]

>I am attaching prtypes.h.

It appears you changed export to dllexport before you attached it?

>I tried building the code changing export to dllexport where we have #defined (XP_MAC) line 150.

Ah, there is a bug in cpp.ansi where I confused the #if on line 80 with #elif on line 150.

>Is it O.K to build the code by changing export to dllexport or can there be some consequences.

Well export isn't recognized. I don't know if MF C changed after dllexport was implemented? The only places google finds is is in some comments on a MS web page.
And due to the warning they are all ignored.
You could compile with -Bhidden or try to use as is.

You can also fix your problem by compiling with -Dexport=dllexport.

[Steve_The_King]

Thanks for all the help and guidance you are providing :-)


I jus want to make clear that shall we define a new variable Dexport and then build it our code using this flag.

What if I continue using dllexport instead of export ?

[Dennis Handly]

>I just want to make clear that shall we define a new variable Dexport and then build it our code using this flag.

I was suggesting you use a command line -D to rename it. Of course if you have a variable with the name "export" you would have problems.

>What if I continue using dllexport instead of export?

Whatever is easier.

[Steve_The_King]

Thanks :-)

I was able to continue with my build for the time being.