489882 - Building with "NECKO_DISK_CACHE=" fails with unresolved external symbol: "nsDiskCache::Hash(char const *,unsigned int)" referenced in function "DCacheHash(char const *)" (nsDiskCacheDeviceSQL)

Status: RESOLVED FIXED

(Calendar :: Build Config, defect)

Description

[Marco Perez [:mpk]]

Attachment: buildlog snippet

Since March 27 building Sunbird on FreeBSD fails near the end of the build.
This bug seems to have been introduced with the changeset 999999125311 (see
bug 290032, attachment 368619 [details] [diff] [review]).

Comment 1

[Marco Perez [:mpk]]

Attachment: band-aid patch for un-breaking the build (comm-central)

It looks like MOZ_STORAGE has gotten dependant upon NECKO_DISK_CACHE.
I'm unsure whether this patch may serve as a real solution or if it's
merely a workaround.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Isn't this a storage issue, not a disk cache one?

Comment 3

[Shawn Wilsher :sdwilsh]

Uh, storage should not be dependent on the disk cache AFAIK.

Comment 4

[Boris Zbarsky [:bzbarsky]]

nsDiskCacheDeviceSQL includes nsDiskCache.h, and has since its initial landing.  It used to not use this for anything, as far as I can tell; the patch in bug 290032 just added a use of nsDiskCache::Hash.  The implementation of this function is in netwerk/cache/src/nsDiskCacheDevice.cpp, so if that doesn't get built you get the link error in this bug.  The NECKO_DISK_CACHE define affects whether that C++ file is built, but NOT whether nsDiskCacheDeviceSQL.cpp is built.  So... should nsDiskCacheDeviceSQL not be built ifndef NECKO_DISK_CACHE?  Or should the Hash() impl move to a different file (one always built)?  Or something else?

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Are we still having these Problems in some form? The Sunbird builds are green.

Comment 6

[Marco Perez [:mpk]]

(In reply to comment #5)
> Are we still having these Problems in some form? The Sunbird builds are green.

The problems seem to persist. I still get the same errors as (see the first
attachment) when building Sunbird from current trunk (using mozilla-central)
on FreeBSD-Stable.

Are you referring to the tinderbox builds? Aren't these builds based on
mozilla-1.9.1 instead of mozilla-central? They shouldn't be affected at all
I think (but I could be mistaken).

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Oh, now I understand, sorry. Yes, I meant the tinderbox builds, but this issue is obviously with mozilla-central.

Comment 8

[Stefan Sitter [:ssitter]]

Some days ago the comm-central branch switched back to using mozilla-central. 
I now see a similar linker error trying to build on Windows 7:

> Creating library sunbird.lib and object sunbird.exp
> 
> necko.lib(nsDiskCacheDeviceSQL.obj) : error LNK2019: unresolved
> external symbol "public: static unsigned int __cdecl
> nsDiskCache::Hash(char const *,unsigned int)"
> (?Hash@nsDiskCache@@SAIPBDI@Z) referenced in function "unsigned
> __int64 __cdecl DCacheHash(char const *)"
> (?DCacheHash@@YA_KPBD@Z)
> 
> sunbird.exe : fatal error LNK1120: 1 unresolved externals

Comment 9

[Marco Perez [:mpk]]

Attachment: v2 (since the first one broke due to bit-rot)

The original band-aid patch hasn't been working for some time now.
This one applies cleanly to the current trunk.

Comment 10

[Marco Perez [:mpk]]

Stefan's comment seems to indicate that this bug may affect all platforms.
Setting to All since we don't seem to have any Sunbird tinderboxen compiling
from the trunk proving otherwise.

Comment 11

[Stefan Sitter [:ssitter]]

Comment on attachment 409583 [details] [diff] [review]
v2 (since the first one broke due to bit-rot)

Enabling disk cache for Sunbird is only a workaround and I don't know what that means for Sunbird.

Mozilla toolkit offers an option to turn off disk cache. Either this option should be fixed to work correctly or it should be removed.

Comment 12

[Benjamin Smedberg]

It's definitely not a supported option... it existed for very small device embedders, IIRC, but nobody has volunteered to maintain that configuration. This is either WONTFIX or you ask the necko maintainer if it's ok to remove the option entirely.

Comment 13

[zunda]

Attachment: A modification on mozilla/netwerk/cache/src/Makefile.in which made a build of sunbird successful

I ran into the same problem and got sunbird built with editing Makefile.in as attached on a Linux machine (Momonga Linux 6) with make -f client.mk.

.mozconfig is:
ac_add_options --enable-application=calendar
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
mk_add_options MOZ_MAKE_FLAGS="-j4"
mk_add_options MOZ_CO_PROJECT=calendar

status of my working copy is:
$ cd mozilla
$ LANG=C hg parents
changeset:   34849:63bd5af8386b
tag:         tip
user:        Mark Finkle <mfinkle at mozilla.com>
date:        Fri Nov 13 23:23:00 2009 -0500
summary:     Bug 507817: BorderImage should not call ExtractCurrentFrame each time it draws [r=dbaron r=joedrew]

$ LANG=C hg status
M netwerk/cache/src/Makefile.in

Comment 14

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v3

As far as I can tell, the disk cache enables network documents to be cached locally. The default settings are to enable the disk cache with 50mb. If Sunbird decides to enable this, we should be careful. We probably don't want calendar data to be cached via the necko disk cache, so we should make sure that calendar data requests are always made bypassing the cache, or we should disable the disk cache via pref.

On the other hand, Thunderbird is built with the disk cache enabled, and it seems this hasn't bothered Lightning, so it might be fine to just enable the disk cache for Sunbird. Since we don't offer prefs for the disk cache, we should nevertheless disable it in Sunbird though. Stefan, do you agree?

Comment 15

[Martin Schröder [:mschroeder]]

Comment on attachment 416275 [details] [diff] [review]
Fix - v3

r=mschroeder

Comment 16

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Moving to calendar again since the issue was fixed there.

Comment 17

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/45c6417d7688>
and comm-191 default <http://hg.mozilla.org/releases/comm-1.9.1/rev/e62c7d571be0>

-> FIXED

Comment 18

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".