449453 - SeaMonkey Build (comm-central) fails in LDAP on FreeBSD 7

Status: RESOLVED FIXED

(Directory :: LDAP C SDK, defect)

Description

[Marco Perez [:mpk]]

Attachment: unbreaks the build on FreeBSD7 (should do no harm on earlier versions)

While trying to build SeaMonkey from the new mercurial-based repository I got
the following error:

[snip]
rm -f libmozldap.so
c++ -I/usr/X11R6/include  -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pipe  -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-z,defs -Wl,-h,libmozldap.so -o libmozldap.so  nsLDAPProtocolModule.o nsLDAPMessage.o nsLDAPConnection.o nsLDAPOperation.o nsLDAPURL.o nsLDAPServer.o nsLDAPService.o nsLDAPBERValue.o nsLDAPControl.o nsLDAPBERElement.o nsLDAPModification.o nsLDAPProtocolHandler.o nsLDAPSecurityGlue.o     -pthread   -Wl,-rpath-link,../../../../mozilla/dist/bin  -L../../../../mozilla/dist/bin -lxpcom -lxpcom_core -L../../../../mozilla/dist/bin `../../../../mozilla/nsprpub/config/nspr-config --prefix=../../../../mozilla/dist --libdir=../../../../mozilla/dist/lib --libs` -L../../../../mozilla/dist/bin -L../../../../mozilla/dist/lib -lldap60 -lprldap60 -lldif60  -Wl,-Bsymbolic -lm    
nsLDAPBERElement.o(.text+0x81): In function `nsLDAPBERElement::GetAsValue(nsILDAPBERValue**)':
: undefined reference to `ber_flatten'
nsLDAPBERElement.o(.text+0xad): In function `nsLDAPBERElement::GetAsValue(nsILDAPBERValue**)':
: undefined reference to `ber_bvfree'
nsLDAPBERElement.o(.text+0x10c): In function `nsLDAPBERElement::PutSet(unsigned int*)':
: undefined reference to `ber_put_set'
nsLDAPBERElement.o(.text+0x153): In function `nsLDAPBERElement::StartSet(unsigned int)':
: undefined reference to `ber_start_set'
nsLDAPBERElement.o(.text+0x1d4): In function `nsLDAPBERElement::PutString(nsACString_internal const&, unsigned int, unsigned int*)':
: undefined reference to `ber_put_ostring'
nsLDAPBERElement.o(.text+0x235): In function `nsLDAPBERElement::Init(nsILDAPBERValue*)':
: undefined reference to `ber_alloc_t'
nsLDAPBERElement.o(.text+0x290): In function `nsLDAPBERElement::~nsLDAPBERElement()':
: undefined reference to `ber_free'
nsLDAPBERElement.o(.text+0x2d0): In function `nsLDAPBERElement::~nsLDAPBERElement()':
: undefined reference to `ber_free'
gmake[7]: *** [libmozldap.so] Error 1
gmake[7]: Leaving directory `/work/build/suite/directory/xpcom/base/src'
gmake[6]: *** [libs] Error 2
gmake[6]: Leaving directory `/work/build/suite/directory/xpcom/base'
gmake[5]: *** [libs] Error 2
gmake[5]: Leaving directory `/work/build/suite/directory/xpcom'
gmake[4]: *** [libs_tier_app] Error 2
gmake[4]: Leaving directory `/work/build/suite'
gmake[3]: *** [tier_app] Error 2
gmake[3]: Leaving directory `/work/build/suite'
gmake[2]: *** [default] Error 2
gmake[2]: Leaving directory `/work/build/suite'
gmake[1]: *** [build] Error 2
gmake[1]: Leaving directory `/work/src'
gmake: *** [build] Error 2
[/snip]

I created a patch which unbreaks the build on my machine. I remember having
used those additional lines for CVS-based builds on FreeBSD 6 for a while
without noticing any side-effects, so earlier versions of FreeBSD as well as
Firefox/Thunderbird/Sunbird/XULRunner/SeaMonkey (those were the only ones I
built) shouldn't suffer any regressions with this patch. But I'd like to get
confirmation from an independent builder who has access to a machine running
FreeBSD 6 or earlier nevertheless. Except of course if this patch is considered
as bearing no or low risk.

Comment 1

[Marco Perez [:mpk]]

Ooops, I thought accepting the bug would automatically assign it to me.
Sorry for the bugspam.

Comment 2

[Mark Smith [:mcs]]

I do not have access to a computer that runs FreeBSD.  I suspect this patch is low risk.

Comment 3

[Mark Smith [:mcs]]

Comment on attachment 332578 [details] [diff] [review]
unbreaks the build on FreeBSD7 (should do no harm on earlier versions)

r=mcs.

Rich, do you know if a decision was made about where LDAP development will take place going forward (Hg vs. CVS trunk)?  Do we need to commit this in two places?

Comment 4

[Rich Megginson]

I would prefer to move to hg.  We have hg on all of our clients, and it's included in the MozillaBuild package for Windows.  hg is a lot nicer than CVS for distributed, disconnected development.

Comment 5

[Marco Perez [:mpk]]

Attachment: this one fixes static builds as well

Static builds are still busted, even with the patch. Same symptoms as described
in bug 320977 (I don't want to rule out the possibility that my tests that lead
to its closure back then were flawed). This affects Thunderbird, since "make
package" requires to build static. This requirement isn't going away anytime soon, is it?

Linking against libcompat fixes the problem (isn't there a cleaner solution)?
Compatibility with older FreeBSD releases shouldn't be a problem, libcompat is
already mentioned in the FreeBSD 2.0.5 manpages.

Not requesting review for now, since I'm still unsure about which aproach we
should choose. Comments are very welcome. :-)

Comment 6

[Marco Perez [:mpk]]

Attachment: new version of a functioning patch (applicable to Mozilla CVS)

Switching to the libxul build broke the known workarounds for SeaMonkey.
Besides, -lcompat never seemed to be supported on amd64. And re_comp as
well as re_exec have actually been marked as obsolete since FreeBSD 2.0. 

Switching to regcomp/regexec (see regex(3)) might require quite an effort,
so for now it may be best to just switch on NEED_BSDREGEX for FreeBSD.
This patch works around the conflict with <unistd.h>.

It seems to fix the SeaMonkey builds, but I have yet to test it thoroughly
building Thunderbird and Sunbird (all the way up to "gmake package").

Comment 8

[Landry Breuil (:gaston)]

Adding my voice here, i also need a similar workaround to build thunderbird 3.3alpha2 on OpenBSD, otherwise it fails with missing syms for re_comp/re_exec.

- switch NEED_BSDREGEX for OpenBSD
- add const to re_comp/re_exec prototypes to workaround the conflict with unistd.h which is being included anyway.

i'll post an updated patch as for thunderbird the dir is ldap/sdks/c-sdk, and not directory/c-sdk.

Did someone consider switching to regcomp/regexec ? it'll make very much sense.. instead of using a function dating back to 4.0BSD..

Comment 9

[Marco Perez [:mpk]]

Comment on attachment 481338 [details] [diff] [review]
new version of a functioning patch (applicable to Mozilla CVS)

My last patch has suffered from bitrot. The new path was introduced when
the LDAP SDKs were imported into the mercurial repository, so it's the
same for Thunderbird and SeaMonkey. I don't think I encountered any
problems with the latest patch back then, but I'll have to test with
some slight changes and current trunk.

Comment 10

[Ludovic Hirlimann [:Usul]]

(In reply to comment #9)
> Comment on attachment 481338 [details] [diff] [review]
> new version of a functioning patch (applicable to Mozilla CVS)
> 
> My last patch has suffered from bitrot. The new path was introduced when
> the LDAP SDKs were imported into the mercurial repository, so it's the
> same for Thunderbird and SeaMonkey. I don't think I encountered any
> problems with the latest patch back then, but I'll have to test with
> some slight changes and current trunk.

Can you reupload your latest version of the patch ?

Comment 11

[Landry Breuil (:gaston)]

For the record, here are thepatches i'm using on OpenBSD, updated from https://bugzilla.mozilla.org/attachment.cgi?id=481338&action=diff. The 'defined(freebsd)' should be changed to 'defined(FREEBSD)', from the original patch.

http://rhaalovely.net/cgit/seamonkey/tree/patches/patch-ldap_sdks_c-sdk_ldap_include_portable_h?h=sm-2.1
http://rhaalovely.net/cgit/seamonkey/tree/patches/patch-ldap_sdks_c-sdk_ldap_include_regex_h?h=sm-2.1
http://rhaalovely.net/cgit/seamonkey/tree/patches/patch-ldap_sdks_c-sdk_ldap_include_portable_h?h=sm-2.1

Comment 12

[Mark Banner (:standard8)]

Landry, can you actually attach the patches to the bug, then we can request review on them and I'll help drive those through.

Comment 13

[Landry Breuil (:gaston)]

Attachment: Fix build on freebsd/openbsd

Here you are.. i added the s/freebsd/FREEBSD/ change while here, but i left out the c-sdk/ldap/libraries/libldap/Makefile.in chunk from https://bugzilla.mozilla.org/attachment.cgi?id=481338&action=diff as i'm not sure it's required for freebsd. Marco ?

Comment 14

[Marco Perez [:mpk]]

This seems indeed to be required. Lots of undefined references to 'ber_...'
in ../../staticlib/components/libmozldap.a(nsLDAPBERElement.o) and a broken
build without this part of the patch. SeaMonkey and Thunderbird are both
affected. Just tested on FreeBSD 8-Stable (amd64).

Comment 15

[Landry Breuil (:gaston)]

Attachment: Fix build on freebsd/openbsd

Okay, so here's the full patch with the Makefile.in bit...

Ideally, switching to regcomp/regexec might be better :)

Comment 16

[Mark Banner (:standard8)]

Comment on attachment 518302 [details] [diff] [review]
Fix build on freebsd/openbsd

Looks good to me, but Rich should have the final sign-off here.

Comment 17

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/projects/ldap-sdks/rev/c208c0671acc

I've filed bug 641495 about getting this into the Thunderbird builds by default.