446451 - missing cygpath called by cygwin-wrapper in pre-configured MSYS when building directory

Status: RESOLVED WORKSFORME

(Thunderbird :: Build Config, defect)

Description

[Christoph Hannebauer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: version 3.0a2pre (2008072119)

I downloaded the MozillaBuild package from http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites today and got the latest(?) source via CVS. I tried to build Thunderbird by executing

./configure --enable-application=mail
make

This did not work, because mozilla/directory/c-sdk/config/cygwin-wrapper calls an executable "cygpath" which does not come with MSYS from the Mozilla page.

Reproducible: Always

Steps to Reproduce:
1. Install the build prerequisites Windows SDK 6.0, Visual Studio 2008 and copy the missing oleacc.idl as described here: http://developer.mozilla.org/en/docs/oleacc.idl
2. start c:\mozilla-build\start-msvc9.bat
3. Use CVS to get the mozilla source
4. navigate to the mozilla directory and execute ./configure --enable-application=mail
5. execute make
Actual Results:  
an error message "cygwin-wrapper: cygpath: command not found" appears when /directory is linked, together with error "LNK1146"

Expected Results:  
there should be a cygpath file in the MSYS/bin directory. I used the one from http://synfig.org/Mingw_installation#cygpath_emulation , although I don't know about its copyright. However, adding such a cygpath file worked for me.

Comment 1

[Mark Banner (:standard8)]

You shouldn't need cygpath to build this. The standard installation has been working fine for most people.

Please could you try changing the following steps:

> 3. Use CVS to get the mozilla source
> 4. navigate to the mozilla directory and execute ./configure
> --enable-application=mail
> 5. execute make

to

3. Use CVS to get the mozilla source.
4. Create a file called ".mozconfig" in the mozilla/ directory (i.e. where configure is) with the following contents:

mk_add_options MOZ_CO_PROJECT=mail
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-tb
ac_add_options --enable-application=mail

5. run "make -f client.mk build" from the same directory.

If you still get problems you should try asking on the newsgroup news://news.mozilla.org:119/mozilla.dev.builds which has been set up to support these types of issues.

(In either case, please report back here your progress so that we can deal with the bug in the appropriate manner).

Comment 2

[Christoph Hannebauer]

I deleted the cygpath file, added a .mozconfig file with the values Mark gave me and executed "make -f client.mk build".

I had a couple of problems, probably because I've used the same source for my earlier builds. After "make distclean", I got back to the original error message:

(...)

======= making ./nsldif32v60.dll
sh /d/TestProgs/thunderbird-head/mozilla/directory/c-sdk/config/cygwin-wrapper l
ink  -OPT:REF -nologo -MAP -DLL -PDB:NONE  -SUBSYSTEM:CONSOLE    -out:"nsldif32v
60.dll" ./line64.obj  -DEF:/d/TestProgs/thunderbird-head/mozilla/directory/c-sdk
/ldap/libraries/libldif/../msdos/winsock/nsldif32.def
/d/TestProgs/thunderbird-head/mozilla/directory/c-sdk/config/cygwin-wrapper: cyg
path: command not found
LINK : fatal error LNK1146: no argument specified with option '/DEF:'
make[6]: *** [nsldif32v60.dll] Error 122

(...)

I will try to download the source code fresh from CVS and follow Mark's steps right from the beginning. If this brings the cygpath error message again, I will post the problem to the newsgroup mozilla.dev.builds 

Comment 3

[Christoph Hannebauer]

The error appears even with completely fresh sources from CVS. I will post the details in the newsgroup mozilla.dev.builds.

Comment 4

[Christoph Hannebauer]

The people at mozilla.dev.builds gave a lot of tipps (thanks!) and we eventually found out  that the problem doesn't occur with the latest Comm-central Mercurial sources. Therefore I close the bug as fixed.

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> The people at mozilla.dev.builds gave a lot of tipps (thanks!) and we
> eventually found out  that the problem doesn't occur with the latest
> Comm-central Mercurial sources. Therefore I close the bug as fixed.
> 
We typically use Works for me when we don't know which patch actually fixed the bug.