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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mpk, Assigned: mcs)
Details
Attachments
(1 file)
(deleted),
patch
|
cls
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•19 years ago
|
||
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+
Reporter | ||
Comment 3•19 years ago
|
||
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).
Comment 4•19 years ago
|
||
Should we use the POSIX regex functions regcomp, regexec instead of the BSD re_comp and re_exec? Are the former more portable?
Assignee | ||
Comment 5•19 years ago
|
||
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.
Comment 6•19 years ago
|
||
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.
Comment 7•19 years ago
|
||
If I recall correctly, re_comp is considered as LEGACY nowadays.
So unsure if LDAP should depend on it.
Comment 8•18 years ago
|
||
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.
Comment 9•18 years ago
|
||
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.
Assignee | ||
Comment 10•18 years ago
|
||
(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?
Comment 11•18 years ago
|
||
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.
Assignee | ||
Comment 12•18 years ago
|
||
(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.
Comment 13•18 years ago
|
||
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?
Reporter | ||
Comment 14•18 years ago
|
||
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?
Comment 15•18 years ago
|
||
No objections. Please mark it closed if it works.
Reporter | ||
Comment 16•18 years ago
|
||
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.
Reporter | ||
Comment 17•18 years ago
|
||
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.
Description
•