Fix libical integration

RESOLVED FIXED in mozilla1.3beta


Build Config
15 years ago
13 years ago


(Reporter: Curtis Jewell, Assigned: hacker formerly known as


Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(3 attachments, 6 obsolete attachments)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021107
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021107

mozilla/configure does not detect a libical that was built from the Visual
Studio Environment from mozilla/other-licences/libical/src/libical.dsw in
mozilla/other (VS6 SP5, Debug build) and placed in a LIB directory that it
should be able to find because it is being passed the wrong command line to
compile the detection routine. (cl -o conftest  -W3 -nologo -Gy -Fd$(PDBFILE)  
conftest.c -lical   kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib
advapi32.lib 1>&5 at line 10844)

I run a script in order to do the build, and commenting out the
--enable-calendar line in .mozconfig allows a successful build.

Source from 5 Nov 2002 tarball.

Reproducible: Always

Steps to Reproduce:
1. Compile libical and place as noted.
2. Compile mozilla under cygwin bash with script and .mozconfig as noted.

Actual Results:  
Error message as displayed under $ configure in the "extra information"
attachment, and config.log created with contents in the same attachment.

Expected Results:  
A successful build, with the calendar included.

Comment 1

15 years ago
Created attachment 105424 [details]
extra information file

This is the "extra information" mentioned earlier - the contents of the
config.log file, the contents of the build script, and output of uname and
configure, as well as showing the location of the libical library.

Comment 2

15 years ago
Assignee: mikep → mostafah
Ever confirmed: true

Comment 3

15 years ago
The .dsw file is not really supported and updated regularly. I suggest you use
the same cygwin bash shell and gmake to compile libical for windows. This will
solve your problem.
Reporter: Is there any special reason you compiled with the Visual Studio
Environment and not from command line?

Comment 4

15 years ago
I used Visual Studio because no other way to build the provided libical worked 
for me.

make = gmake 3.79.1, so that's correct. (I assume mozilla would not build 

Here's the current contents of that directory (I deleted the tree and re-
extracted the tarball.)

Curtis@FAMILY-WMGNLMMU /src/mozilla/other-licenses/libical
$ ls
AUTHORS    LICENSE      README    examples      zoneinfo
COPYING    Makefile     TEST        config.h
CVS  THANKS  scripts
ChangeLog  TODO        design-data   src
INSTALL    NEWS         acconfig.h  doc           test-data

Here's what happens when I try to use make in that directory on Makefile on - Am I using the right command lines? (didn't do a configure step 
because I didn't see a script in that directory - should I have run 
first?  The makefile that doing that and running configure created ended it's 
build with a build error, too!)

$ make
Makefile:27: ../..//config/ No such file or directory
../..//config/ ../..//config/ No such file or director

make: *** No rule to make target `../..//config/'.  Stop.

Curtis@FAMILY-WMGNLMMU /src/mozilla/other-licenses/libical
$ make -f *** missing separator.  Stop.

Also note that part of the reported problem is with configure generating an 
incorrect command line for cl.exe - it needs to say "libical.lib" and not "-
lical", if I understand what cl /? is telling me.

Comment 5

15 years ago
OK. Found the directions in and made a script 
to do them: (sorry about earlier)


setenv CVSROOT
cd /src/mozilla
setenv MOZ_TOOLS /cygdrive/c/moztools
setenv MOZCONFIG ~/.mozconfig
setenv PATH ...
setenv LIB ...
cd other-licenses/libical
./ --prefix=/usr --disable-python-bindings
make install
cd /src/mozilla
make -f build_all_depend

Here's what happened...

$ ./moztest
WARNING: aclocal's directory is /usr/autotool/devel/share/aclocal, but...
         no file /usr/autotool/devel/share/aclocal/glib.m4
         You may see fatal macro warnings below.
         If these files are installed in /some/dir, set the ACLOCAL_FLAGS
         environment variable to "-I /some/dir", or install

WARNING: Using auxiliary files such as `acconfig.h', `'
WARNING: and `', to define templates for `'
WARNING: is deprecated and discouraged.

WARNING: Using the third argument of `AC_DEFINE' and
WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
WARNING: `acconfig.h':

WARNING:             [Define if a function `main' is needed.])

WARNING: More sophisticated templates can also be produced, see the
WARNING: documentation.
autoheader: `' is created installing `./install-sh' installing `./mkinstalldirs' installing `./missing'
examples/ installing `./depcomp'
src/libical/ CLEANFILES must be set with `=' before using `+=' installing `./ylwrap'
automake: processing Makefiles another time to fix them up.
src/libical/ CLEANFILES must be set with `=' before using `+='
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for bison... no
checking for byacc... no
checking for gcc... gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking whether ln -s works... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... ./config.guess: unable to guess system type

This script, last modified 2002-01-02, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <> in order to provide the needed
information to handle your system.

config.guess timestamp = 2002-01-02

uname -m = xx
uname -r = 5.1
uname -s = WINNT
uname -v = 2600

/usr/bin/uname -p = unknown
/bin/uname -X     =

hostinfo               =
/bin/universe          =
/usr/bin/arch -k       =
/bin/arch              =
/usr/bin/oslevel       =
/usr/convex/getsysinfo =

configure: error: cannot guess build type; you must specify one

Now type 'make' to compile libical.
Makefile:27: ../..//config/ No such file or directory
../..//config/ ../..//config/ No such file or 

make: *** No rule to make target `../..//config/'.  Stop.
Makefile:27: ../..//config/ No such file or directory
../..//config/ ../..//config/ No such file or 

make: *** No rule to make target `../..//config/'.  Stop.
cd /src/mozilla
Adding configure options from /home/Curtis/.mozconfig:
loading cache ./config.cache
checking host system type... i586-pc-msvc
checking target system type... i586-pc-msvc
checking build system type... i586-pc-msvc
checking for cl... cl
checking how to run the C preprocessor... /lib/cpp
checking for mmintrin.h... grep: conftest.out: No such file or directory
checking for icalproperty_new_location in -lical... no
configure: error: Calendar requires libical
*** Fix above errors and then restart with "make -f build"
make: *** [/src/mozilla/Makefile] Error 1


15 years ago
Depends on: 158528

Comment 6

15 years ago
Created attachment 106236 [details] [diff] [review]
Patch to, version 0.8

I've actually got a patch that's "almost ready for prime-time"... the problem
I'm having is still how to build libical using the "in-tree" version! (the
patch currently has a /NODEFAULTLIBS [/NOD] being passed to the linker that I'd
like to get rid of [since the libical.lib I have was a debug version being
linked against a non-debug program], but it got me through the test.)

Comment 7

15 years ago
Comment on attachment 106236 [details] [diff] [review]
Patch to, version 0.8

New patch will be put up in 30 mins to an hour.
Attachment #106236 - Attachment is obsolete: true

Comment 8

15 years ago
Created attachment 107100 [details] [diff] [review]
Patch to build libical automatically on Win32 systems.

Instead of detecting libical on Win32 systems, this patch makes it build
libical instead... so all that has to be done to get a Win32 calendar build is
turn on --enable-calendar in the .mozconfig and build once. It seemed like this
was the best way to handle things.
I'm obsoleting the extra info file now.
Attachment #105424 - Attachment is obsolete: true

Comment 9

15 years ago
This has to be fixed in the toplevel file.
From comment #14 of bug 158528:
There is a test to make sure the libical library is installed for building 
calendar at:
This test is not a valid test on a windows machine. So building using
--enable-calendar with gmake in windows stops at that test.
Note: ical can now be built on windows with gmake which will then provide
ical.lib for calendar to link against
Please see the patch and comments #14 to #16 of bug 158528
Assignee: mostafah → seawood
What is the deal with libical?  At one point, an external version was required,
hence the configure test.  Now, you're saying that an in-tree version is
required.   Is that the permanent solution or are we going to swing back to
requiring the external version?
Comment on attachment 107100 [details] [diff] [review]
Patch to build libical automatically on Win32 systems.

The libical check should be consistent across platforms.  Either everyone uses
the internal version by default or everyone uses the external version by

MOZ_INTERNAL_LIBICAL should not be set by  If we're going to use
that variable at all, then it should follow the precedent set by libart and
require the variable to be set externally since the license on libical differs
from the rest of the tree.
Attachment #107100 - Flags: first-review-
-> Browser:Build Config
Component: Calendar General → Build Config
Product: Calendar → Browser
QA Contact: colint → granrose
Version: unspecified → Trunk

Comment 13

15 years ago
This was my first attempt at hacking Mozilla at all (I have never been accused 
of diving in with both feet)... and only because I was having difficulty 
building this and couldn't believe how inaccurate the directions were.

I'd like to see Mozilla+Calendar easier to build, hence, this bug. (I'm out in 
GMT+9 [.jp], so while an IRC chat might be in order, it's not the easiest for 
me as far as timing is concerned.)

AFAIK, here's the situation: (mostafa, can you correct me?)

Right now, we're on a snapshotted libical (beyond the 0.23 that's currently 
available on libical's site) so we pretty much have to build from the mozilla 
tree's version.

For Linux, eventually libical could be external again, but for Win32, with 
the /NODEFAULTLIBRARY problems I was having creating the test that's in the 
0.8 patch (which we COULD incorporate in as the test for an external Win32 
libical), I assume it'd be a lot easier staying in the tree (that and the "out-
of-tree" version would build a) from a .dsw and b) with the wrong name and c) 
How would you use debug instead of release versions of the library? You 
get "nodefaultlibrary" pains when you go to link!)

I only have a Win32 system here, so I wasn't willing to change Linux/Unix 
build proceedures much. Who would I ask who would be willing to test any Linux 

Let me make sure what you'd want for a positive review on the next suggested 
patch: You'd like MOZ_INTERNAL_LIBICAL to 1) be a switch that's externally 
turned on rather than internally detected, and 2) to work on all systems, 

I can do that, although #2 would be stepping where I can't test. Get back to 
me, OK?

Comment 14

15 years ago
Created attachment 107254 [details] [diff] [review]
Patch to 1) build libical when requested and 2) catch debug/release inconsistency errors on Win32.

This patch catches debug/release inconsistency on Win32 with
MOZ_INTERNAL_LIBICAL off [if it's not caught here, the build will break when
libxpical is linked] as well as implementing (what I thought were) the
requested changes.
Attachment #107100 - Attachment is obsolete: true


15 years ago
Attachment #107254 - Flags: review?(seawood)
Blocks: 182076

Comment 15

15 years ago
Created attachment 108222 [details] [diff] [review]
Patch to build libical internally if MOZ_CALENDAR is set

Currently libical can be simply built by typing make in other-licenses/libical
and it just creates static libraries. Calendar will link to it statically
eliminating the need to provide extra shared libraries.This is now happening
both on linux and windows.
The only thing needed now is to actually make libical when MOZ_CALENDAR is set.

This patch is a simplified version of the previous patch including some tweaks
from patch1 in bug 117682, which will take care of this.
Licensewise, libical is LGPL so there is no harm including and using their code
internally in Mozilla. We will post an announcement to the libical group as
Attachment #107254 - Flags: review?(seawood) → review-
Comment on attachment 108222 [details] [diff] [review]
Patch to build libical internally if MOZ_CALENDAR is set

Shouldn't libical be built before calendar is built?  Libical doesn't look like
it will built properly in an objdir build.  I think I've mentioned that before.
Attachment #108222 - Flags: review-
Summary: "configure" Can't detect libical when building using cygwin bash as command shell. → Fix libical integration
*** Bug 117682 has been marked as a duplicate of this bug. ***
> Licensewise, libical is LGPL so there is no harm including and using their code
> internally in Mozilla.

Actually, because calendar currently statically links against libical, I think
that will cause a problem.  I was under the impression that for the LGPL'd
library to be safe to use, it had to be dynamically linked or have the ability
to be relinked via a separate object file.
Yeah, that's going to be a problem.  We need to make sure that we ship a
seperate .so for the ical library.
Created attachment 108805 [details] [diff] [review]
int v1.0

This patch:
- Causes calendar & libical to be pulled by default
- Builds the internal version of libical & calendar if --enable-calendar is
- Renames libical & libicalss to libmozical & libmozicalss, respectively
- Forces the above libraries to always be shared since they are LGPL. (Do we
need to take the extra step and add the _lgpl suffix like we did for libart?
- Added small changes to build on Darwin
Attachment #107254 - Attachment is obsolete: true
Attachment #108222 - Attachment is obsolete: true
Attachment #108805 - Flags: review?(blizzard)
Comment on attachment 108805 [details] [diff] [review]
int v1.0

Attachment #108805 - Flags: review?(blizzard) → review+
Flags: blocking1.3a?
The patch was checked in though I still have the question about the _lgpl suffix.
Flags: blocking1.3a?
Target Milestone: --- → mozilla1.3beta

Comment 23

15 years ago
Created attachment 109020 [details] [diff] [review]
Patch to add missing symbols to .def files

As a result of changing the static link to a dynamic link, some symbols have to
be added to the .def files otherwise link will be broken on windows.
This patch adds the missing symbols.
Created attachment 109059 [details] [diff] [review]
append _lgpl to library name as well
Attachment #109020 - Attachment is obsolete: true

Comment 25

15 years ago
libical fails to build if cygwin perl is used , because the makefiles -I

which is 

ICALSCRIPTS = $(srcdir)/../../scripts

which is

srcdir = d:/mozbuild/mozilla/other-licenses/libical/src/libical

which perl does not understand 

perl sets INC to 

( D /mozbuild........., xx, xx, xx) note the missing seperator after "D"

i think cygwin perl needs cygwin paths not dos paths
That problem should have been fixed with the last patch.  Perl is detected at
configure time and we use the cygwin-wrapper script to modify the arguments as
necessary to work for cygwin or AS perl.  The problem in this particular case
was the extra space between the -I and the $(ICALSCRIPTS) which broke the script.
Attachment #109059 - Flags: review?(blizzard)
Comment on attachment 109059 [details] [diff] [review]
append _lgpl to library name as well

Attachment #109059 - Flags: review?(blizzard) → review+
Patch has been checked in.  There's still a small problem with building in the
objdir on win32 but there's a patch in bug 171753 that will fix that.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 29

15 years ago
FYI: libical seems to be dual licensed with MPL and LGPL.

Doesn't this mean that we don't need the "other licenses" and the _lgpl stuff???

Comment 30

15 years ago
So it is.  If it can be used under the MPL, then the dynamic libs aren't needed
neither is the _lgpl suffix.  Why was it checked in under other-licenses to
begin with or was the license change a recent event?
Created attachment 109568 [details] [diff] [review]
Revert naming to moz prefix & static libs
Attachment #109568 - Flags: review?(blizzard)
Comment on attachment 109568 [details] [diff] [review]
Revert naming to moz prefix & static libs

Attachment #109568 - Flags: review?(blizzard) → review+
Patch has been checked in.
Just a note: libical is in other-licenses because it is not tri-licensed. In
this particular case, you can use the LGPL's conversion clause to make it GPL
also, so the licensing issue is not complicated. But our policy is
non-tri-licensed stuff goes in other-licenses, so there it is.

Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.