Closed Bug 306907 Opened 15 years ago Closed 13 years ago

Build libsqlite as a standard name separate shared library.

Categories

(Toolkit :: Storage, defect, major)

defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.9alpha7

People

(Reporter: rrelyea, Assigned: sdwilsh)

References

Details

Attachments

(2 files, 13 obsolete files)

I would like  the sqlite we build has a standard name (like libsqlite3.so or
sqlite3.dll) rather than be subsumed in a mozilla storage package.

The reason for this is basically one of sharing code. NSS would like to
eventually use sqlite3 for it's database. I would like to not have to build
sqlite3.dll in NSS itself, however NSS needs to be build standalone (without
mozilla), as it has many non-mozilla customers (mostly servers). As part of this
goal, I'd like to build NSS so it can use the system sqlite if it exists on the
target platform, but still be able to build sqlite for platforms that do not
already supply sqlite.

Thanks,

bob
As discussed on IRC, mozilla sqlite contains bugfixes which must be upstreamed
before we can seriously consider this. Shaver mentioned this, I don't know
exactly what the status was.
And we're planning to have more patches, such as for encrypted storage, which
are unlikely to be accepted upstream.  I'm not sure what the right plan is here,
TBH.
I don't think any of our patches will change the basic non-encrypted database
format.  However, we can probably build sqlite as as static lib in-tree that NSS
can link with if there is no system sqlite.  This would mean that there would be
two copies of sqlite, one in NSS and one in the mozStorage component, though...
Does sqlite have its own configure, or do we lump it with mozilla configure? NSS
does not use the standard mozilla build system (it's stuck in the coreconf dark
ages) and I really don't want to go forking our build system to death.
It doesn't have its own configure, but there's very little to configure.  Some
OS selection happens in the makefiles; at some point we should do an os_nspr
module so that everything goes through NSPR, but other than that there's
nothing.  We depend on some types from nspr, but that's easy to fix (include file).
(In reply to comment #1)
> As discussed on IRC, mozilla sqlite contains bugfixes which must be upstreamed
> before we can seriously consider this. Shaver mentioned this, I don't know
> exactly what the status was.

sdwilsh has gotten (or will have gotten soon) those patches out of the tree now, correct?
The preloader is still not upstream - we plan on working on that after we land the upgrade and just temporarily disable it.

As for encrypted storage - couldn't we just do that as part of the mozIStorage stuff?  Patching the sqlite files ourselves makes it really hard to upgrade...
In reply to comment 2 and comment 7, In comment 2, Shaver wrote:
> And we're planning to have more patches, such as for encrypted storage

AFAIK, there are no SQLite source changes for NSS.  The encryption of data
happens before it is put into the DB, so no DB changes are required.
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #8)
> In reply to comment 2 and comment 7, In comment 2, Shaver wrote:
> > And we're planning to have more patches, such as for encrypted storage
> 
> AFAIK, there are no SQLite source changes for NSS.  The encryption of data
> happens before it is put into the DB, so no DB changes are required.

The encrypted storage model I was talking about was encryption at the page level, such that database metadata was also encrypted, and we don't have to independently add encryption support to every Mozilla caller.  I think it would also tend towards better resistance to cryptanalysis, but my recollections there are very very rusty, so don't take my word for it.

There are existing hooks in sqlite that you can poke with #defines, but the resulting library isn't 100% compatible.  (It's a superset, but I can conceive of mildly pathological cases in which a client could detect it.)
Right now we have a plain vanilla version of sqlite in the tree (baring one windows only fix for async that has a bug filed upstream).  I think it would be in the projects best interest to leave it this way so it makes it easy to upgrade (it wasn't trivial to upgrade to where we are now because of previous patches).

Anything we want to do should try to be pushed upstream.
Attached patch v1.0 (obsolete) — Splinter Review
Bob, if you could find out if this is useable for NSS, that would be great.
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED
Attachment #269306 - Flags: review?(ted.mielczarek)
Attached patch v1.1 (obsolete) — Splinter Review
whoops - extra change in that one that wasn't needed.
Attachment #269306 - Attachment is obsolete: true
Attachment #269308 - Flags: review?(ted.mielczarek)
Attachment #269306 - Flags: review?(ted.mielczarek)
checking it out now...
Arg, I'm running into problems on linux.

sqlite3 has no global external symbols:
bobs-laptop(75) nm -g libsqlite3.so | grep -v ' U '
         w _Jv_RegisterClasses
0008ad28 A __bss_start
         w __cxa_finalize@@GLIBC_2.1.3
         w __gmon_start__
0008ad28 A _edata
0008aec8 A _end
00080ff4 T _fini
00001874 T _init
hmm, so running |nm -g libsqlite3.dylib | grep -v ' U '| on my copy produces a lot of symbols (the functions).  Maybe I did something wrong with this...
Attachment #269308 - Flags: review?(ted.mielczarek)
Comment on attachment 269308 [details] [diff] [review]
v1.1

don't know what's up with linux - I'll have to get some help with that tomorrow.  This patch is also wrong with one line, so I'll get a new one when I've resolved the linux issues...
Attachment #269308 - Attachment is obsolete: true
Presumably we compile with -fvisibility=hidden these days on Linux, and the sqlite header doesn't have any visibility markings, so everything gets hidden.
See http://gcc.gnu.org/wiki/Visibility for info.
Drat - we either need to disable that for this module somehow, or get the sqlite folks to add visibility stuff...
If it helps, I have an export list I used for the NSS version of the library, Is there a way to get mozilla to swallow it? (I can easily convert the format if necessary).

bob
Attached patch turn off hidden for sqlite3 (obsolete) — Splinter Review
This patch gets through the linux builds (needs to be added on top of shawns patch version 1.1).

Ideally we should only add visibility to sqlite3_ functions, but that needs to be pushed upstream.
Bob, can you file a ticket with the sqlite folks and post the link back here to get visibility stuff added as appropriate?
Bob, you might try just setting VISIBILITY_FLAGS= in the sqlite makefile (after it includes autoconf.mk).  That should cause our build system to not pass -fvisibility-hidden.  It might be a cleaner workaround until you get something upstream to sqlite.
I'm having trouble seeing how you could build sqlite as a DLL at all on windows: I don't see any instances of dllexport/import in the .h or .c files, and there isn't a .def file.
Ticket 2448: SQLITE needs to identify public exported symbols

re benjamin: I have a .def file if we need one (I used it in NSS).
re ted: I like that solution better, I'll try it out right away.

bob

This is an example of how we use the def files:
http://mxr.mozilla.org/seamonkey/source/modules/zlib/src/Makefile.in#55
build for Mac PPC and Linux completed.  checking windows now (I expect it to fail without the .def file).
Bob, how did the windows build go (and did you try it with the .def file)?
I did, I ran into some other problems, and didn't get through a complete windows builds. This morning my home network is down, so I'll try to set up a work windows  machine. I'll attach my current patch just now..
This takes Shawn's 1.1 patch and does the following:
1) turn on visibility.
2) restore sqlite3 in the requires line for storage (It turns out most linux and mac machines have sqlite3 installed, so their header files are in the system directory).
3) add directives to use a .def file for windows.

I'll attack the .def file separately.
Attachment #269428 - Attachment is obsolete: true
Attached file .def file for windows (obsolete) —
This is the .def file. I copied it from the NSS tree, so it has the NSS 'directives' that allow it to be used in Unix builds as well as windows builds (The NSS build environment knows how to parse these directives, they are 'cleverly' hidden from windows and OS/2 by windows and OS/2 comments). They can be removed without harm in the mozilla build.

The .def file also includes 2 'internal' functions that mozilla calls.
Shawn,

I've tested these patches on Win2003, WinXP, RHEL5 Linux and, Mac OS X ppc. If you can test Mac Dual I think the patches are good to go.

bob
I probably won't be able to get to this today (or at least for 4 hours) unless I'm directed to by mconnor.  Bob, if this is blocking you guys from landing, send an e-mail to mconnor about the situation please.
This is a blocker for landing nss, but, unless the alpha schedule has changes, The bigger one is alpha code complete is today. NSS 3.12 is a little bit too big of a change to land hours before alpha cutoff;(.

Flags: blocking1.9?
Target Milestone: --- → mozilla1.9beta1
Version: unspecified → Trunk
trying this now - Bob, where does the def file need to go (and what about this map file)?  I'll generate a full patch to get reviewed by Benjamin.
Severity: enhancement → major
Build works and passes storage, download manager, and places unit tests.
Hi Shawn, do we have the patch ready so I can land NSS 3.12? thanks.
Attached patch v2.0 (obsolete) — Splinter Review
If someone could double check that this works in windows, that'd be awesome.
Attachment #269698 - Attachment is obsolete: true
Attachment #269703 - Attachment is obsolete: true
Attachment #271269 - Flags: review?(benjamin)
Attachment #271269 - Attachment is obsolete: true
Attachment #271269 - Flags: review?(benjamin)
Attached patch v2.1 (obsolete) — Splinter Review
So RyanVM was getting crashes with this, but he didn't have symbols so it may have been something else.  Another tester would be nice, and I'm not going to request review until I hear that it's OK for someone.
Attached image Debugger screenshot (obsolete) —
Here's what I'm seeing with the debugger with this patch applied.

Some points of interest:
a) the symbols seem to be being built into xul.pdb instead of a separate pdb file
b) it appears that it's trying to find that function in xul.dll still?

I'm very inexperienced with debugging, so if there's any other info you need, feel free to reply here with directions or catch me in #developers.
Here's a stack for the crash we're getting.

xul.dll!mozStorageService::InitStorageAsyncIO()  Line 515
xul.dll!mozStorageService::Init()  Line 100
xul.dll!mozStorageService::GetSingleton()  Line 68 + 0xb bytes
xul.dll!mozStorageServiceConstructor(nsISupports * aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0012f24c)  Line 51 + 0x1c bytes
xul.dll!nsGenericFactory::CreateInstance()  + 0x1f bytes
xul.dll!nsComponentManagerImpl::CreateInstanceByContractID()  + 0x74 bytes
xul.dll!nsComponentManagerImpl::GetServiceByContractID()  + 0x11e bytes
xul.dll!nsCOMPtr_base::assign_from_gs_contractid_with_error()  + 0x2c bytes
xul.dll!nsNavHistory::InitDBFile(int aForceInit=11781088)  Line 451
xul.dll!nsNavHistory::Init()  Line 284
xul.dll!nsNavHistoryConstructor(nsISupports * aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0012f384)  Line 10 + 0x4c bytes
xul.dll!nsGenericFactory::CreateInstance()  + 0x1f bytes
xul.dll!nsComponentManagerImpl::CreateInstance()  + 0x74 bytes
xul.dll!nsComponentManagerImpl::GetService()  + 0x16f bytes
xul.dll!nsJSCID::GetService()  + 0x295 bytes
xul.dll!_NS_InvokeByIndex_P()  + 0x27 bytes
xul.dll!XPCWrappedNative::CallMethod()  + 0xa26 bytes
xul.dll!XPC_WN_CallMethod()  + 0x127 bytes

I managed to fix the PDB issue by making a small change to the def file, and it appears that I was wrong about the xul.dll thing - the exception was occurring there, but that was saying nothing about where it was looking for sqlite3Os.

Finally, with some guidance from jimm, I ran sqlite3.dll and xul.dll through depends.exe and dumpbin.exe and everything appeared to be kosher there. All of the exported functions showed up properly in sqlite3.dll and xul.dll was properly looking for those functions in sqlite3.dll.

Hopefully that information helps...
is sqlite actually in process at the time of the crash?

http://mxr-test.landfill.bugzilla.org/seamonkey/source/storage/src/mozStorageAsyncIO.cpp#504

fairly evil code there
does someone have that debugger alive?

<bsmedberg> timeless: it seems so unnecessary to take the temporary address

this code doesn't make sense. it's trying to use a struct from another library. does it really think that'll work?

bsmedberg: does your dependent library magic ensure that sqlite is loaded at this point?
<bsmedberg> not with that patch, no. but libxul should have a direct depenency on it, so in the firefox-libxul case that's not an issue.

my guess is that the crash is basically you're trying to write into a missing external structure

<bsmedberg> could be, but it still seems really weird

at least, that'd explain what is shown there

mozStorageService::InitStorageAsyncIO+0x7 is basically sqlite3OsVtbl* vtable = &sqlite3Os;

which is just a math assignment and doesn't actually read the value or ensure you can write to it.

btw, .dmp's + symbolserver, or .cab's with .dmp's and .pdb's are preferred over pictures. especially since the .dmp would let me answer the "is sqlite in memory question". (fwiw, the output window at the bottom right of the screen would have answered that question if it was a lot taller.)
timeless, I'll try to catch you on IRC tonight so I can hopefully get you what you need. I'm learning how to use the debugger as I go here :-)
OK, here's a 7zip archive which includes a dump+heap, plus the PDBs for sqlite, storage, and libxul.
http://www.ryanvm.net/mozilla/dump.7z (22.2MB)

Hopefully that's everything you need. If you need anything else, let me know.
sqlite3Os is a data symbol in the sqlite3 shared library. The line should be

sqlite0SVtbl *vtable = sqlite3_os_switch();

With the proper declaration of sqlite3_os_switch().

bob
Then attachment 270218 [details] [diff] [review] should be backed out.  Technically, that function is depreciated...
So on windows, data symbols aren't available between shared libraries. That's why it's crashing on Windows. We do the same sort of manipulation to share templates between shared libraries in NSS, just so it works on windows.;(.

bob
FWIW, we tried backing out attachment 270218 [details] [diff] [review] a few days ago and making the needed def changes (so basically what you said to try in comment #44), and we still crashed, albeit at a different spot. Unfortunately, I'm not in a position to generate a stack until tomorrow, but if that's the way to go, we can at least diagnose the next crash and progress in the right direction.
(In reply to comment #46)
> So on windows, data symbols aren't available between shared libraries. 

More accurately, on Windows, the address of a data symbol from another 
shared library cannot be used as an initializer for a global or static 
variable or structure member.  IOW, they cannot be used as initializers
for data of storage-classes that are initialized by the OS's loader.

An example of a working cross-shared-lib DATA item is the array 
SSL_ImplementedCiphers[].  It is exported in ssl.def and is declared in 
ssl.h with a macro that expands (on Windows) to 
extern __declspec(dllimport) 
So, after having declared it as 
extern __declspec(dllimport) const PRUint16 SSL_ImplementedCiphers[];
It can be referenced in executable code, and in initializers of automatic
pointers, but not in initializers of static or external data elements.
E.g. in a function,
void foo(void) {
    static const PRUint16 *cipherSuites = SSL_ImplementedCiphers;  // fails
    const PRUint16 *cipherSuites = SSL_ImplementedCiphers;         // works
    cipherSuites = SSL_ImplementedCiphers;                         // works
Attached patch Fix symbol export (obsolete) — Splinter Review
This additional patch makes patch v2.1 work on my system. Probably won't work on other platforms, but it's just a matter of putting the right ifdefs in to make it work.
Thanks Michael. I'll play with this patch tomorrow and see if I can get it playing nicely with gcc too.
I think the sqlite3Os DATA line in the .defs file should be sufficient. The .def file is windows only, so there shouldn't be an impact on other platforms.

bob
(In reply to comment #51)
> I think the sqlite3Os DATA line in the .defs file should be sufficient. The
> .def file is windows only, so there shouldn't be an impact on other platforms.
> 
> bob
> 
I was not able to run firefox without the change to sqlite3file.h. The SSL code mentioned before does the same thing.
Attached patch v2.2 (obsolete) — Splinter Review
Incorporates all changes to date.  Testing on mac now, I'll have testing on Linux and Windows in a bit.
Attachment #271313 - Attachment is obsolete: true
Attachment #271369 - Attachment is obsolete: true
Attachment #271954 - Attachment is obsolete: true
Attached patch v2.3 (obsolete) — Splinter Review
whoops, local change of adding SQLITE_DEBUG to the DEFINES made it in...
Attachment #272037 - Attachment is obsolete: true
Attachment #272038 - Flags: review?(benjamin)
Attached patch v2.4 (obsolete) — Splinter Review
OK, with patch v2.3 applied, win32 libxul builds compile and run fine, all the mozStorage xpcshell tests all pass without any problems. Win32 static builds are another issue, however.

As-applied, win32 static builds fail outright due to not being able to link to the sqlite3 library. Removing the erroneous EXPORT_LIBRARY = 1 from db/sqlite3/src/Makefile.in (sdwilsh has already made this change locally on his end) and adding the following to config/static-config.mk allows the build to compile:

ifdef MOZ_STORAGE
EXTRA_DSO_LIBS += sqlite3
endif

This appears to work quite well. Firefox launches OK and Places (bookmarks & history) and the Download Manager seem to be working like they should. On the other hand, all of the mozStorage xpcshell tests fail with a "failed to get nsJSRuntimeService!" error message. From what I've been able to determine, however, that failure is completely unrelated to this patch as it's also happening for me on static builds without this patch applied. I've gone ahead and filed bug 388162 for that problem.

I'm posting a patch which brings things to the state I just talked about. I've also confirmed that this patch doesn't break shared+libxul and vanilla shared win32 builds. Obviously, this still needs Linux & OSX testing and the static tests should probably be confirmed to run OK (once bug 388162 is fixed) before this can be safely called working.

I'm going to be going out of town for a week tomorrow, so I probably won't be around to help see this to its conclusion, but I think it's very close to being ready for review now.
Attachment #272038 - Attachment is obsolete: true
Attachment #272320 - Flags: review?(benjamin)
Attachment #272038 - Flags: review?(benjamin)
Comment on attachment 272320 [details] [diff] [review]
v2.4

You will also need to add a notation to http://mxr.mozilla.org/mozilla/source/xpcom/stub/Makefile.in#96 to inform embedders that libxul depends on a new sharedlib.
Attachment #272320 - Flags: review?(benjamin) → review+
Attached patch v2.5 (for checkin) (obsolete) — Splinter Review
added line as per request
Attachment #272320 - Attachment is obsolete: true
Checking in config/static-config.mk;
new revision: 3.38; previous revision: 3.37
Checking in db/sqlite3/src/Makefile.in;
new revision: 1.23; previous revision: 1.22
Checking in db/sqlite3/src/sqlite.def;
initial revision: 1.1
Checking in db/sqlite3/src/sqlite3file.h;
new revision: 1.7; previous revision: 1.6
Checking in storage/build/Makefile.in;
new revision: 1.9; previous revision: 1.8
Checking in toolkit/library/libxul-config.mk;
new revision: 1.46; previous revision: 1.45
Checking in xpcom/stub/Makefile.in;
new revision: 1.16; previous revision: 1.15
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Well, that didn't take long at all :(

rm -f libstoragecomps.so
c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe  -DDEBUG -D_DEBUG -DDEBUG_cltbld -DTRACING -g -fno-inline -fPIC -shared -Wl,-z,defs -Wl,-h,libstoragecomps.so -o libstoragecomps.so  mozStorageModule.o    -lpthread          -Wl,--whole-archive ../src/libstorage_s.a  -Wl,--no-whole-archive -L../../dist/bin -L../../dist/lib -lsqlite3 -L../../dist/bin -lxpcom -lxpcom_core  -L../../dist/bin -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L../../dist/bin -lmozjs   -Wl,-Bsymbolic -ldl -lm    
/usr/bin/ld: ../src/libstorage_s.a(mozStorageAsyncIO.o)(.text+0x1a1f): unresolvable relocation against symbol `sqlite3Os'
/usr/bin/ld: final link failed: Nonrepresentable section on output

Backed out....
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yeah, that's a side-effect of visibility. Probably the easiest way to workaround that is to add the SQLite headers to the system-headers list:
http://mxr.mozilla.org/mozilla/source/config/system-headers
I'm a little confused as to why this matters on the tinderboxen, since everyone that I've had try this with Linux builds has had no problems with this...
Because most current distros don't have a compiler that's new enough to support the visibility pragma properly, so we disable it in configure.
ok, so I should just add sqlite3file.h to the system-headers file and it should work (that is where the symbol is defined)?

Do I need to attach a new patch and have you review it?
You're going to need sqlite3.h and sqlite3file.h, and any other headers that define exported symbols.

Oh, and you might need to set VISIBILITY_FLAGS= in the sqlite makefile as well.

Sounds like this is a prime candidate for a buildbot try patch ;-) No, you don't need additional review, though it would be nice to find somebody who sees this problem and can verify that your fix works properly.
already have |VISIBILITY_FLAGS =| in the makefile, and the only symbol it is complaining about is in sqlite3file.h.
Attached patch v2.6Splinter Review
This is what I'll try first thing tomorrow when I get (assuming the tree is open and green).
Attachment #272509 - Attachment is obsolete: true
Missing the .def on purpose?
yup - I managed to not back it out in the first place:
http://mxr.mozilla.org/seamonkey/source/db/sqlite3/src/sqlite.def
Looks like this one went off without any problems. :)

Checking in config/static-config.mk;
new revision: 3.40; previous revision: 3.39
Checking in config/system-headers;
new revision: 3.17; previous revision: 3.16
Checking in db/sqlite3/src/Makefile.in;
new revision: 1.25; previous revision: 1.24
Checking in db/sqlite3/src/sqlite3file.h;
new revision: 1.9; previous revision: 1.8
Checking in storage/build/Makefile.in;
new revision: 1.11; previous revision: 1.10
Checking in toolkit/library/libxul-config.mk;
new revision: 1.49; previous revision: 1.48
Checking in xpcom/stub/Makefile.in;
new revision: 1.19; previous revision: 1.18
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
latest Win32 zip build including the 2007-07-18 11:43 checkin

sqlite3.dll is missing

Minefield won't start
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The installer seems to work - not sure what's up with the zip builds (didn't try them myself)
The zip build from 2007-07-18-12 has sqlite3.dll in the install dir. and starts fine for me. Resolving as FIXED again.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
My trunk builds started failing with libsqlite3 linker errors shortly after this checkin. I didn't have the static devel package installed, so I installed it and verified that libsqlite3.a is in /usr/lib/. I had the shared library with proper symlinks. I tried wiping my source tree and doing a full CVS checkout. I tried adding --enable-storage to my ~/.mozconfig. I can see -lsqlite3 in the link at the end of the build. I can't figure out what the problem is. I am using gcc version 4.2.1 20070712 (prerelease) and GNU ld version 2.17.50.0.9 20070103.

This is a sample of the errors.

../../staticlib/components/libstoragecomps.a(mozStorageService.o): In function `mozStorageService::Init()':
mozStorageService.cpp:(.text+0xeb): undefined reference to `sqlite3_enable_shared_cache'

...

../../staticlib/components/libstoragecomps.a(mozStorageAsyncIO.o):mozStorageAsyncIO.cpp:(.text+0x3d3): more undefined references to `sqlite3Os' follow
../../staticlib/components/libstoragecomps.a(mozStorageAsyncIO.o): In function `ProcessAsyncMessages()':
mozStorageAsyncIO.cpp:(.text+0x66e): undefined reference to `sqlite3ApiExit'
As this broke OS/2 again (at the rate of one or two breaks per day we can hardly do any real work on our port ;-)) we need something like this patch to get going. 

I guess that if we want to maintain only one list of exports we should better put this only into a new file and use the ADD_TO_DEF_FILE trick for both OS/2 and Windows?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Just an FYI in case anyone is interested. The linker errors that I had appear to have been caused by the -Wl,--as-needed option I had in my LDFLAGS. I am not sure if there is an incompatibility with the sqlite3 library that is being built or if it's a binutils/ld bug.
Depends on: 390292
Resolving.  This made it in for M7.  OS/2 build bustage is tracked with Bug  	390292.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9 M8 → mozilla1.9 M7
Flags: blocking1.9?
This change breaks external linkage / dynamic linking  against gecko-libs (libxul.so).

sqlite3Os symbol is included in gecko libsqlite3.so but is missing in the upstream one.

libxul.so is built against gecko libsqlite3.so and it requires sqlite3Os. If libxul.so is dynamically linked against some external application (for instance epiphany), system-wide libsqlite3.so is used with libxul.so and the sqlite3Os symbol is missing.

(In reply to comment #77)
> This change breaks external linkage / dynamic linking  against gecko-libs
> (libxul.so).
> 
> sqlite3Os symbol is included in gecko libsqlite3.so but is missing in the
> upstream one.
> 
> libxul.so is built against gecko libsqlite3.so and it requires sqlite3Os. If
> libxul.so is dynamically linked against some external application (for instance
> epiphany), system-wide libsqlite3.so is used with libxul.so and the sqlite3Os
> symbol is missing.
Please file a new bug?  This bug has been beaten to death.
Blocks: 504523
You need to log in before you can comment on or make changes to this bug.