Closed Bug 1143322 Opened 10 years ago Closed 4 years ago

./configure with --enable-application=suite gives moz.build illegal file access

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Version:
SeaMonkey 2.33 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: linuxcbon, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 Build ID: 20150224201851 Steps to reproduce: download seamonkey-2.33.source.tar.bz2 untar the file go to directory comm-release ./configure --disable-dbus --disable-pulseaudio --disable-gstreamer --disable-necko-wifi --enable-application=suite Actual results: ============================== ERROR PROCESSING MOZBUILD FILE ============================== The error occurred while processing the following file: /tototo/comm-release/mozilla/moz.build The underlying problem is an illegal file access. This is likely due to trying to access a file outside of the top source directory. The path whose access was denied is: /tototo/comm-release/suite/app.mozbuild Modify the script to not access this file and try again. Expected results: ./configure runs ok
Getting this as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
What is the contents of your mozconfig file?
Flags: needinfo?(linuxcbon)
(In reply to Philip Chee from comment #2) > What is the contents of your mozconfig file? There is no mozconfig involved, so the TOPSRCDIR is somehow set to two different things depending if you're on c-c or c-c/mozilla. (That's my prelim. guess.)
(In reply to Edmund Wong (:ewong) from comment #3) > (In reply to Philip Chee from comment #2) > > What is the contents of your mozconfig file? > > There is no mozconfig involved, so the TOPSRCDIR is somehow > set to two different things depending if you're on c-c or c-c/mozilla. > (That's my prelim. guess.) this is correct, I didn't create any mozconfig . Note : with a mozconfig , it works OK.
Flags: needinfo?(linuxcbon)
(In reply to linuxcbon from comment #4) > (In reply to Edmund Wong (:ewong) from comment #3) > > (In reply to Philip Chee from comment #2) > > > What is the contents of your mozconfig file? > > > > There is no mozconfig involved, so the TOPSRCDIR is somehow > > set to two different things depending if you're on c-c or c-c/mozilla. > > (That's my prelim. guess.) > > > this is correct, I didn't create any mozconfig . > Note : with a mozconfig , it works OK. With this settled, I'm unsure how to proceed. While theoretically speaking, this bug can be settled as WFM; but, in essence, this build config bug is an issue. Without the mozconfig, the build config system uses two different TOPSRCDIR variables. I'm wondering if this is related to not using fullpaths in MOZ_OBJ_DIR. jcranmer, what would you suggest? Is it possible to get the build system to 'deduce' (without having a mozconfig file or a MOZCONFIG env set) what it's building (without needing to hardcode anything, i.e. if currentdir has mozilla/, we're building a comm-* source)? (no idea really.. just saying)
Flags: needinfo?(Pidgeot18)
(In reply to Edmund Wong (:ewong) from comment #5) > With this settled, I'm unsure how to proceed. If you read the bug title, this only happens with enable-application=suite , the problem comes from there : When I do : ./configure --disable-dbus --disable-pulseaudio --disable-gstreamer --disable-necko-wifi WORKS OK When I do : ./configure --disable-dbus --disable-pulseaudio --disable-gstreamer --disable-necko-wifi --enable-application=suite --> BUG linuxcbon
(In reply to Edmund Wong (:ewong) from comment #5) > With this settled, I'm unsure how to proceed. While theoretically > speaking, this bug can be settled as WFM; but, in essence, this > build config bug is an issue. > > Without the mozconfig, the build config system uses two different > TOPSRCDIR variables. I'm wondering if this is related to not > using fullpaths in MOZ_OBJ_DIR. > > jcranmer, what would you suggest? Is it possible to get the > build system to 'deduce' (without having a mozconfig file or > a MOZCONFIG env set) what it's building (without needing to > hardcode anything, i.e. if currentdir has mozilla/, we're > building a comm-* source)? (no idea really.. just saying) At present, I've been considering a mozconfig a requirement to build comm-central applications. I haven't poked at the mozilla buildsystem in gory detail, but when I last touched this part of configure, the default guesses for what happens without mozconfig caused TOPSRCDIR confusion in late parts of the build system. (In reply to linuxcbon from comment #6) > When I do : > ./configure --disable-dbus --disable-pulseaudio --disable-gstreamer > --disable-necko-wifi > WORKS OK But you build firefox, where the topsrcdir confusion actually ends up causing the right thing to happen.
Flags: needinfo?(Pidgeot18)
In reply to comment #8: this is a different problem, it belongs in a different bug. I think I saw another bug (by you) about it but I cannot find it back. The rule is: one issue, one bug.

As building with mozconfig is the supported way of doing things -> WONTFIX

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.