User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072612 GranParadiso/3.0.1 Build Identifier: trunk When building thunderbird from comm-central, make install only proceeds if BUILD_STATIC_LIBS is true. A simple build with "--enable-application=mail --disable-installer" has no problem installing on Linux but only if you hack the Makefile. Reproducible: Always Steps to Reproduce: 1.Build comm-central with "--enable-application=mail and optionally --disable-installer" 2.Afterwards, cd to the object directory and run make install Actual Results: Exited with 'you need a "--enable-static --disable-shared" build to create an installer' Expected Results: The files should have been copied into $prefix or if specified $DESTDIR/$prefix

This error can be taken out on Linux so the patch checks for OS_ARCH=Linux. The error might also be pointless on other platforms, anyone want to check?

I'm not quite sure, but I've always had the feeling that that message would be more accurate as "if your platform has a MOZ_PKG_MANIFEST, you must have built with the sort of libs it expects" - the issue being that packager.mk is going to call package-stage before it actually installs, and package-stage is going to use the MOZ_PKG_MANIFEST if there is one. Since Standard8 has plans for adding one for Linux, probably the right order of tests is more like if (platform with MOZ_PKG_MANIFEST) if (non-static) error out elif (Windows) MOZ_PKG_MANIFEST_P = ... [eventually] elif (Linux) MOZ_PKG_MANIFEST_P = ...

(In reply to comment #2) > I'm not quite sure, but I've always had the feeling that that message would be > more accurate as "if your platform has a MOZ_PKG_MANIFEST, you must have built > with the sort of libs it expects" - the issue being that packager.mk is going > to call package-stage before it actually installs, and package-stage is going > to use the MOZ_PKG_MANIFEST if there is one. I hadn't actually thought of it this way. I was more thinking that "when we ship Thunderbird, we use static builds, because you are 'shipping' Thunderbird, you should do the same". However your packaging point is also good. Maybe make package/installer should enforce this restriction (IMHO on all platforms) and make install doesn't need to - assuming make install isn't relying on the package manifests.

make install does use the package manifest if it's defined, that's why I'm saying that the test order should make it clear that the only way to escape the static requirement is by being a platform which doesn't have a package manifest. With Connor's patch, it wouldn't be at all clear that someone adding a unix/packages-static would need to undo his patch and get Linux back under the static-only branch. And since package-compare has added enough benefit to having a package manifest that I've switched sides to thinking we should have one, we should probably just wontfix this in favor of that, and then hurry up about getting to where we can enable libxul, at which point the default build will be something you can make install on, unless you specify enable-debug.

Comment on attachment 337167 [details] [diff] [review] Tentative fix Phil, given the recent changes we should decide what we want to do with this bug. I think dmose can advised but isn't really going to be concerned too much about it. Therefore passing the review to you as a reminder to take a look at it.

I still think I had it right in comment 4: nobody actually *wants* to install a shared build, they just want to |make install| on whatever the default build happens to be. We could take a patch that defaults to static ifndef DEBUG if someone feels like writing one, but otherwise we'll get there once we switch to libxul.