Closed Bug 320977 Opened 19 years ago Closed 18 years ago

Building Seamonkey (or LDAP-enabled Firefox) aborts with error

Categories

(Directory :: LDAP C SDK, defect)

x86
FreeBSD
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mpk, Assigned: mcs)

Details

Attachments

(1 file)

When building Seamonkey the build process aborts with the following error (in NativeAppSupportBase.cpp, almost at the end of the building process): ... ../../dist/bin/libldap50.so: undefined reference to `re_comp' ../../dist/bin/libldap50.so: undefined reference to `re_exec' gmake[4]: *** [seamonkey-bin] Error 1 ... The output when building an LDAP-enabled Firefox is basically the same (in StaticComponents.cpp, quite late in the building process as well): ... ../../dist/bin/libldap50.so: undefined reference to `re_comp' ../../dist/bin/libldap50.so: undefined reference to `re_exec' gmake[5]: *** [firefox-bin] Error 1 ... This bug may be FreeBSD-specific.
I'm not sure whether this is the right approach, but with this patch applied I was able to build both Seamonkey and Firefox with LDAP enabled.
Attachment #206409 - Flags: review?(cls)
Comment on attachment 206409 [details] [diff] [review] first attempt at creating a suitable patch On which version of FreeBSD does the problem occur? The change looks fine to me but I'm midly concerned that -lcompat wasn't needed with previous FreeBSD releases. We may want to consider creating a configure check for that in bug 318149.
Attachment #206409 - Flags: review?(cls) → review+
I experienced the problem on 6.0. Your suggestion about bug #318149 sounds reasonable. I'm gonna try building on the 4.11 and the 5.4 releases as well, but I'm afraid I won't get around to trying this until after christmas. As a side note, the man pages for "re_exec" and "re_comp" start mentioning libcompat in the 4.3 release (see http://www.freebsd.org/cgi/man.cgi).
Should we use the POSIX regex functions regcomp, regexec instead of the BSD re_comp and re_exec? Are the former more portable?
On many platforms, the LDAP code uses its own regex code, found in: mozilla/directory/c-sdk/ldap/libraries/libldap/regex.c Not a great thing to do these days. Maybe we still need that on Win32, but I bet we could just use the POSIX functions almost everywhere now.
AFAIK, win32 has no regex or match functions supplied as part of the base OS or free SDKs, either as part of the Win32 API or the POSIX API. What we were thinking of doing is using regcomp/regexp on those platforms that support it (use an autoconf test to find it?) and perhaps just use the old regex code on those platforms that don't support it. Or, if the posix regcomp source code is reasonably self contained and Mozilla license friendly, we could just incorporate that source code into the ldap c sdk.
If I recall correctly, re_comp is considered as LEGACY nowadays. So unsure if LDAP should depend on it.
We just need something that is cross platform. Since MS provides no native regex api (AFAIK - someone please correct me if I'm wrong) we have to provide our own regex implementation on Windows. Everywhere else we can just use POSIX regcomp/regexp.
Grr. This seems like a lot of effort just to support getfilter.c, which looks like the only place in the entire library+command line tools that uses regular expressions.
(In reply to comment #9) > Grr. This seems like a lot of effort just to support getfilter.c, which looks > like the only place in the entire library+command line tools that uses regular > expressions. Yes, I think that is the only place. Is it difficult to switch to the POSIX functions?
The only difficulty is adding POSIX regcomp/regexec on Windows. I found the glibc code for the POSIX regex implementation which is LGPL licensed. Would it be ok to include this code in libutil? I note that libutil also has a getopt() for Windows, and libutil is only compiled on Windows.
(In reply to comment #11) > The only difficulty is adding POSIX regcomp/regexec on Windows. I found the > glibc code for the POSIX regex implementation which is LGPL licensed. Would it > be ok to include this code in libutil? I note that libutil also has a getopt() > for Windows, and libutil is only compiled on Windows. We really need code that is triple licensed. Can we just use the older regex.c code on Windows? Less convenient, I know.
Hmm - looking at the code, it looks as though there already is a configure test that should make the build use the built-in regex code - configure.in:1001: *-bsdi*) AC_DEFINE(XP_UNIX) AC_DEFINE(BSDI) AC_DEFINE(NEED_BSDREGEX) If NEED_BSDREGEX, the code will build and use ldap/libraries/libldap/regex.c: ... #if defined( macintosh ) || defined( DOS ) || defined( _WINDOWS ) || defined( NEED_BSDREGEX ) || defined( XP_OS2) #include "regex.h" ... I'm not sure if this code was in the earlier mozilla client branch used by seamonkey. The client branch is now using a recent (6 months ago or sooner) version of the ldap c sdk code, so this may very well work in the latest builds. Could you please try this again?
I'm not sure whether it's because of the new LDAP C SDK code, but I've been able to successfully build Firefox (with ldap and ldap-experimental, on FreeBSD 6 stable) from current trunk without having to patch it first. I'll try the same with Seamonkey just to be on the safe side. Are there any objections against marking this bug as fixed if Seamonkey builds without any problems?
No objections. Please mark it closed if it works.
Seamonkey builds as well with ldap-experimental enabled. I've only tested shared builds however, as static builds are busted since around July 13th. I'll check out some earlier sources and rebuild static. But so far it looks promising.
Static builds okay with sources from 2006-07-12. Marking as fixed. :-)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: