New LDAP code doesn't build on OpenVMS. Patch coming...
Created attachment 77085 [details] [diff] [review] Make it build on OpenVMS These are the changes I need to to get the new LDAP code to compile and link on OpenVMS.
This should be filed on the Directory product.
Assignee: seawood → mcs
Component: Build Config → LDAP C SDK
Product: Browser → Directory
QA Contact: granrose → nobody
-> dmose (I do not plan to commit any changes to ldapcsdk_50_client_branch myself in the near term) I have no way of testing these changes, but I don't think they will break other platforms. But can you explain the mozilla/directory/c-sdk/ldap/libraries/libldap/open.c changes? Does OpenVMS support pthreads?
Assignee: mcs → dmose
> Does OpenVMS support pthreads? Yes, but pthread_self() is not a routine. Under normal conditions pthread_self() gets turned into some inline assembler code. So there's no routine address which you can save. My change is to force pthread_self to be the actual pthread_self routine so that we do have an address which we can stash away. So how will these changes get checked in? Can I go the usual r/sr/a route, or doesn't that apply to the LDAP code?
I really need to get this in for 1.0. Marking so.
Target Milestone: --- → mozilla1.0
Comment on attachment 77085 [details] [diff] [review] Make it build on OpenVMS r=mcs, but I'd like to see a comment added to open.c to explain the #undef pthread_self, etc.
Attachment #77085 - Flags: review+
By the way, I think the usual r/sr/a process is being used for LDAP checkins to ldapcsdk_50_client_branch. Dan? I plan to pull all of these porting changes back into the trunk once things settle down a bit. In the future, new LDAP features will go into the trunk and then onto the client branch once the Mozilla client team decides they want them.
Yes, the normal r,sr,a process is the way to go for branch checkins.
Assignee: dmose → colin
I see that I'm not building in libssldap. Should I be? Should configure be getting run with -with-nss somehow?
For the browser, that won't be necessary. We'll be using libprldap and PSM for the SSL stuff, not libssldap.
Created attachment 77277 [details] [diff] [review] Revised patch Revised patch for OpenVMS. Includes comment for pthread_self fix, and is merged with other recents ldap changes. I have an r= from mcs. Can I get an sr= from dmose?
Attachment #77085 - Attachment is obsolete: true
For better or worse, I'm not a superreviewer.
Comment on attachment 77277 [details] [diff] [review] Revised patch Carrying mcs's review stamp forward. email@example.com, but consider fixing "its" to be "it's" in that comment ("its inline assembler code"). /be
Comment on attachment 77277 [details] [diff] [review] Revised patch a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77277 - Flags: approval+
Checked in to ldapcsdk_50_client_branch branch.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
When I moved my change from Makefile to Makefile.in, the lines got inserted into the wrong target (LIBPRLDAP instead of DLLPRLDAP). I never caught it because in the LDAP build the Makefile in NOT automatically recreated when Makefile.in is changed. Arghh!! I'll be posting a new patch for approval.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 78171 [details] [diff] [review] Correct patch This patch puts the OpenVMS specific link commands into the DLLPRLDAP target where they belong, and NOT the LIBPRLDAP target.
Comment on attachment 78171 [details] [diff] [review] Correct patch a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #78171 - Flags: approval+
Checked in. new revision: 126.96.36.199; previous revision: 188.8.131.52
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
Spam for bug 129472
QA Contact: nobody → nobody
You need to log in before you can comment on or make changes to this bug.