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. 3. 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.

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.

->mostafa

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?

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 otherwise.) 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 autogen.sh examples zoneinfo COPYING Makefile TEST config.h makefile.win CVS Makefile.am THANKS configure.in scripts ChangeLog Makefile.in 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 makefile.win - 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 autogen.sh first? The makefile that doing that and running configure created ended it's build with a build error, too!) $ make Makefile:27: ../..//config/autoconf.mk: No such file or directory ../..//config/config.mk:38: ../..//config/autoconf.mk: No such file or director make: *** No rule to make target `../..//config/autoconf.mk'. Stop. Curtis@FAMILY-WMGNLMMU /src/mozilla/other-licenses/libical $ make -f makefile.win makefile.win:25: *** 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.

OK. Found the directions in http://www.mozilla.org/projects/calendar/installation.html and made a script to do them: (sorry about earlier) #!/bin/tcsh setenv CVSROOT :pserver:anonymous@cvs-mirror.mozilla.org/:cvsroot cd /src/mozilla setenv MOZ_TOOLS /cygdrive/c/moztools setenv MOZCONFIG ~/.mozconfig setenv PATH ... setenv LIB ... cd other-licenses/libical ./autogen.sh --prefix=/usr --disable-python-bindings make make install setenv MOZ_CALENDAR 1 cd /src/mozilla make -f client.mk 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 /usr/autotool/devel/share/aclocal/glib.m4. WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' 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: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `config.h.in' is created configure.in: installing `./install-sh' configure.in: installing `./mkinstalldirs' configure.in: installing `./missing' examples/Makefile.am: installing `./depcomp' src/libical/Makefile.am:227: CLEANFILES must be set with `=' before using `+=' configure.in: installing `./ylwrap' automake: processing Makefiles another time to fix them up. src/libical/Makefile.am:227: 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 ftp://ftp.gnu.org/pub/gnu/config/ 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 <config-patches@gnu.org> 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 = UNAME_MACHINE = xx UNAME_RELEASE = 5.1 UNAME_SYSTEM = WINNT UNAME_VERSION = 2600 configure: error: cannot guess build type; you must specify one Now type 'make' to compile libical. Makefile:27: ../..//config/autoconf.mk: No such file or directory ../..//config/config.mk:38: ../..//config/autoconf.mk: No such file or directory make: *** No rule to make target `../..//config/autoconf.mk'. Stop. Makefile:27: ../..//config/autoconf.mk: No such file or directory ../..//config/config.mk:38: ../..//config/autoconf.mk: No such file or directory make: *** No rule to make target `../..//config/autoconf.mk'. Stop. cd /src/mozilla /src/mozilla/configure Adding configure options from /home/Curtis/.mozconfig: --enable-calendar --disable-mailnews --enable-crypto --disable-composer 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 yes checking for icalproperty_new_location in -lical... no configure: error: Calendar requires libical *** Fix above errors and then restart with "make -f client.mk build" make: *** [/src/mozilla/Makefile] Error 1

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 on attachment 106236 [details] [diff] [review] Patch to configure.in, version 0.8 New patch will be put up in 30 mins to an hour.

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.

This has to be fixed in the toplevel configure.in file. ->Seawood@netscape.com From comment #14 of bug 158528: ----------------------------------- There is a test to make sure the libical library is installed for building calendar at: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=configure.in&root=/cvsroot&subdir=mozilla&command=DIFF_FRAMESET&rev1=1.947&rev2=1.948 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

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 default. MOZ_INTERNAL_LIBICAL should not be set by configure.in. 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.

-> Browser:Build Config

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 changes? 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, correct? I can do that, although #2 would be stepping where I can't test. Get back to me, OK?

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.

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 well.

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.

*** 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.

This patch: - Causes calendar & libical to be pulled by default - Builds the internal version of libical & calendar if --enable-calendar is specified - 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

Comment on attachment 108805 [details] [diff] [review] int v1.0 r=blizzard

The patch was checked in though I still have the question about the _lgpl suffix.

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.

libical fails to build if cygwin perl is used , because the makefiles -I $(ICALSCRIPTS) 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.

Comment on attachment 109059 [details] [diff] [review] append _lgpl to library name as well r=blizzard

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.

FYI: libical seems to be dual licensed with MPL and LGPL. see http://www.softwarestudio.org/libical/UsingLibical/node4.html Doesn't this mean that we don't need the "other licenses" and the _lgpl stuff???

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?

Comment on attachment 109568 [details] [diff] [review] Revert naming to moz prefix & static libs r=blizzard

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. Gerv