284118 - Firefox 1.0.1 build fails on Mac OSX in the printpde and default plugin components/modules

Status: RESOLVED DUPLICATE of bug 271719

(Firefox Build System :: General, defect)

Description

[Dave Chand]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050227 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050227 Firefox/1.0.1

When compiling the firefox using CFLAGS=-fast -mcpu=7450 and CXXFLAGS=-fastf
-mcpu=7450 the build fails at the printpde components and default plugins
components. 

It seems the these two components are built in $(top_srcdir)/../java_build.
but the install portion of the make files have them located at build/.

I do not believe this happends when the CFLAGS and CXXFLAGS are unset.



Reproducible: Always

Steps to Reproduce:
1.set CFLAGS and CXXFLAGS 
2.compile firefox.
3.

Comment 1

[Ben Fowler]

See Bug 268323 "Make fails to build PrintPDE plugun when build tree on netatalk 
server"

I have also had other problems, less interesting than that one with the 
PrintPDE plugin.

Could you attach the error messages that you get?

Comment 2

[Dave Chand]

Attachment: firefox Default plugin build error message

I have attached the error messaage

Comment 3

[Ben Fowler]

O.K.

I have come up with three ideas. The first, though straightforward is unlikely
to be the cause of your problem. The second you have probably already tried.

The third is a long shot, and here is is:

I am a bit bothered that you have a java_build directory and an optimized_build
directory.

I suggest that you remove the Makefiles for the relevant part of the tree
(or all Makefiles containing the string 'java_build') and recreate
them with a commad like ../src/configure .

Temporarily take the exisiting Default Plugin.plugin bundle (if any) 
out of the picture by renaming it, by changing to the directory 
/Users/dave/src/mozilla/firefox_optimized_build_dir/modules/plugin
and typing 

mv samples/default/mac/build/Default\ Plugin.plugin
samples/default/mac/build/Default\ Plugin.plugin.old

(that should be on one line). 

And then re-trying by typing make.

If this works then the problem could be/have been that the bundle
Default\ Plugin.plugin contained links to non-existent files
or directories.

If this doesn't work and/or you think that it is bad advice, please post
again.

Comment 4

[Ben Fowler]

I meant to add see Bug 205974 especially Bug 205974 Comment 11 .

Comment 5

[Dave Chand]

I tried grepping through the source looking for a "java_build" string anywhere,
but could not find any. What I ended up doing was editing Makefile.in and
putting the correct directory where the plugin was built in there.

Comment 6

[Ben Fowler]

I don't think that you will find the java_build (I had assumed it was directory
that you had decided upon) anywhere in the source tree. I would expect to find
it in your .mozconfig (or equivalent) and from there copied into the Makefiles.

I wouldn't recommend editing Makefile.in, but if it is a temporary and
works, fair enough. If I was on the right lines earlier, then I am confident
that even if that worked, it was not necessary - there would exist a solution
that was either simpler or safer ...

Comment 7

[Dave Chand]

Actually the CFLAGS and CXXFLAGS do not matter the build will still fail at the
said points. 

Comment 8

[Dave Chand]

Attachment: my .mozconfig file

Comment 9

[Ben Fowler]

(In reply to comment #8)
> Created an attachment (id=176082) [edit]
> my .mozconfig file

Thank you.

> mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firefox_optimized_build_dir

I am suggesting that it is possible that you once had a .mozconfig
in which the OBJ_DIR was java_build ; and after the change, some
of the Makefiles with the old setting were not over-written.

My proposal is that you identify those Makefiles (with find and grep)
and remove them. A command like ../configure will recreate them.

I am not quite sure you could have Makefiles in your current OBJ_DIR
with bogus info concerning your OBJ_DIR, so perhaps I am wrong.

Per comment 5 , are you still unable to build?

Comment 10

[Dave Chand]

Whenever I build from a release source I erase and previous sources that may
remain. This error occurs regardless of wheather its a clean build or not a
clean build. 
After I manually edit the make file and hardcode the eventual path of the
plugins the build proceeds fine.
I also never had an object directory named "java_build".

I believe that this only occurs when I specify some other object directory other
than the mozilla source dir.

Have you ever tried building with a specified object dir?
I am going to try building without specificy the object dir and see what happens.

Comment 11

[Dave Chand]

*** This bug has been marked as a duplicate of 271719 ***

Comment 12

[Ben Fowler]

Attachment: Working .mozconfig

(In reply to comment #8)
> Created an attachment (id=176082) [edit]
> my .mozconfig file

This .mozconfig has an OBJ_DIR, and the OBJ_DIR is not only in a different
tree, it is on a different computer and a different architecture.

Comment 13

[Ben Fowler]

(In reply to comment #10)
> Whenever I build from a release source I erase and previous sources that may
> remain. This error occurs regardless of whether its a clean build or not a
> clean build. 

Erasing the sources is probably not necessary, but you may want to 
pay some attention to your build tree: This is what I had in mind when
I wrote comment 3 . You will need to remove build products with incompatible
settings and switches (or at least ensure that they are out of date and will
be re-made); you will definitely need to remove all intermediate files
with faulty paths.

This process is best thought of using the slightly violent concept of
'clobber'.

I am certainly not saying that the build system is easy to take in at one
go. See Bug 202120 "build system does not attempt to rebuild dependencies 
that live in other modules" for a note as to the only qualified way to rebuild
a tree. The documentation has improved by an order of magnitude since then.

> After I manually edit the make file and hardcode the eventual path of the
> plugins the build proceeds fine.

If I read that correctly, then I repeat: Fair Enough, but you still ought to
ensure that you can recreate the Makefiles from the checked out sources and
your own configuration.

> I also never had an object directory named "java_build".

O.K. I am puzzled as to where the name 'java_build' came from. Using grep on 
my (working) source tree, finds nothing I can put put finger on, starting 'java_',
but these lines, ending '_build', may be significant,

./allmakefiles.sh:MAKEFILES_build="build/Makefile"
./allmakefiles.sh:        build) add_makefiles "$MAKEFILES_build" ;;

or here,

./mozilla/build/unix/modules.mk:BM_DIRS_build   = build  
./mozilla/build/unix/modules.mk:BM_CVS_build    = build  

however, I doubt it.

Neither expression had any matches in my build directory. I hope that you can
see that I thought that a directory containing a segment 'java_build' was
something that you had created as a configuration step.

> I believe that this only occurs when I specify some other object directory other
> than the mozilla source dir.

O.K., but I don't see that myself.

> Have you ever tried building with a specified object dir?

Yes, works well, with some stated and unstated provisos, and in fact is strongly 
recommended. I can build Thunderbird, Sunbird and Firebird in the same tree.

I can't quite build Composer at all.

I am sorry that I don't seem to have been much help to you.