128565 - [BeOS]Removed dependency on environment variables for startup

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Paul]

There are two environment variables that are modified by run-mozilla.sh in order to get
Mozilla to run under BeOS.  These are ADDON_PATH and LIBRARY_PATH.  The default settings
for these variables include the <appdir>/addon and <appdir>/lib directories respectively.
By creaeting these directories under the dist/bin directory, moving all of the .stub
files to the addon directory, all the .so files that are components, to the components
directory, and the shared libraries to the lib directory, mozilla-bin CAN run without 
changing the environment variables.  (I have done this manually)

On a system built w/o crypto enabled (I need to check this yet), the only .so files that
need/should be in the lib directory are:
libgkgfx.so  
libjsj.so  
libmozjs.so  
libnspr4.so  
libplc4.so  
libplds4.so  
libxpcom.so 

The security build scripts do not generate the .stub files for their libraries, even
though I believe they are loaded as components, which, if that is the case, their build
scripts probably need to be modified, to avoid the BeOS addon "bug".

The .stub files are generated within rules.mk (search for BEOS_ADDON), and should be
easy to modify.  Making sure each library get installed to the proper position, i.e.,
lib or components should be easy (most are already going to components, and can stay that
way).

What I need to know is, where, in the build process (which file), should the addon
directory be created?  I've been digging through everything, but the build process is so
huge, one can get lost very easily.

BTW, by doing this, mozilla can behave more like a native BeOS app, which is a VERY
good thing.

Comment 1

[Paul]

Chris, once I get this figured out, I might need your help getting the changes for the
nspr build scripts committed.  (I don't think I have access to that branch).

Comment 2

[Paul]

Ok, scratch how I said to do it above, I've got it working by doing the following:

$ mkdir add-ons
$ mkdir lib
$ find . -name "*.stub" -exec mv {} add-ons/ \;
$ mv components/*.so lib/
$ cd components/
$ for file in `ls ../lib/*.so`; do ln -s $file `basename $file`;done
$ cd ..
$ mv *.so lib/
$ ./mozilla-bin  

What I said earlier does not work, since it seems some of the components have
interdependencies, and when they try to load the library they need, they can't,
since the components directory is on to the LIBRARY_PATH.

Now, we have a problem.  How can we get the build scripts to reproduce this? 
Actually, I don't think it is possible, since what we currently do is just zip
up the dist/bin dir for distributions, which converts symbolic links.   I have a
feeling this will have to be an extra step.  Please, if I'm wrong, tell me!!

Comment 3

[hacker formerly known as [e-mail]]

Well, it looks like something we'd build into the actual 'install' target that
I'm working on for bug 56601.  So for clarity, what should the final directory
structure look like?  And what about a development package.  Would that be put
in a separate 'unix' location like /boot/local/{include,lib} or would it go into
the application dir?

Comment 4

[Paul]

Attachment: dir listing of bin/ with mods to remove dependency on env vars

This is a "ls -laR" of the bin directory after performing the steps I
mentiioned earlier to remove the dependency on the envrionment varabile changes

performed in run-mozilla.sh.
Once other step I would do, though I did not do this here, would be to remove
the mozilla shell script completely, and rename mozilla-bin to mozilla.

The install should install to /boot/apps/Mozilla
The development package (I'm guessing you mean the libraries), should install
to /boot/home/config/lib and the stubs to /boot/home/config/add-ons/Mozilla

Comment 5

[Paul]

oh, and the include for development would be:
/boot/home/config/include/Mozilla

Comment 6

[Paul]

I started looking at this again.  It seems the MOZILLA_1_3_BRANCH has had a
patch applied which adds a new variable COMPONENTS_PATH.  If I set the to "lib",
and change the ".stub" generation code, I can get most of the build set so that
the directory structure matches that of a standard BeOS app, and the startup
script is not needed.

Chris, I was wondering if you could answer a couple of questions:
1- Where did the changes in the MOZILLA_1_3_BRANCH for rules.mk come from?
2- What are, if any, the adverse affects of changing COMPONENTS_PATH?
3- How can I get the "dist_bindir" value changed for nsprpub and c-sdk?

Thanks

Comment 7

[hacker formerly known as [e-mail]]

1) The COMPONENT_PATH changes had been in the tree for awhile.  They were added
back when we were trying to support building multiple gfx/widget components in
the same tree.  The non-default components would be installed into the
"inactive" subdir.  That variable was removed when the tree opened for 1.4a.
2) For beos, probably nothing except it probably won't allow those components to
be registered unless they are under bin/components/.
3) You'd have to modify mozilla/configure.in (at the very bottom) & pass
--with-dist-bindir=/foo nspr & ldap's configure scripts.

Comment 8

[Sergei Dolgov]

In reality, all we need to get rid of startup shell script,
is folder with name "lib" under mozilla folder
where we should symlink all *.so -s to.
Don't know if it may be done only by packager,
or need earlier creation of lib folder with symlinks in mozilla/dist

Comment 9

[Paul]

The load_add_on call in prlink.c also needs to be given the proper path, if is
not already, since all addon "stubs" are in the component directory, not a
"addon" directory, as is standard under BeOS.

Also, some of the libraries that are needed by mozilla, are in the root
directory, not the component directory.  Their build scripts (security, c-sdk,
etc) need to be modified, so that the libs are placed in a lib directory under
dist/bin.

The way the packager works now, is it mainly just "zips" the dist/bin dir, IIRC,
substituting links with their actuall folders.  So, for the packager, we would
need to some how distinguish between real libs under the lib directory, and
those that should be symlinked under the lib directory.

Also, how would we deal with "new" components being installed, i.e. extensions.
 If they need to install new libs, we would no longer be "standard", since a
symlink would also need to be created to their new lib in the component dir.

So, in other words, this is not "simple".

Comment 10

[Sergei Dolgov]

Attachment: expanding existing libpath for stub abd libs download

Why not try just this simple way? As there is already "BeOS-localized" path for
loading components in prlink.c

Comment 11

[Paul]

Are you sure that works?  I have not tried it yet, but, LIBRARY_PATH is set on my box,so, that would never with what you changed.  Plus, mozilla-bin is itself linked againstsome of the libraries, so, without modifying LIBRARY_PATH before trying to launch mozilla-bin, you get a link error, before any code is executed.  The "easy" way to fix this would be to modify the default definition of LIBRARY_PATHglobally, but, that is a hack.After looking into this, I don't think we need to worry about the ADDON_PATH, since, itseems the full path to the stub is given to load_add_on.  So, the only thing we need todo is, when adding a library to the dist/bin dir, create a sym-link to it from a newdist/bin/lib dir.  Then, modify the xpinstall code, so that, the sym-links under thelib dir, remain as links (currently stores the actual files, and not the link)I am in the process of looking into this issue again, partly related to some of the workI did on the IPC port code.  I will get it working, one way or another.

Comment 12

[Sergei Dolgov]

Ooops, that patch works only in case of failure, i should rework it a bit - we
need to add those two paths to ev string even if getenv wasn't failed.

Comment 13

[Paul]

Setting the priority, so I can better organize the issues in bugzilla I need to
take care of

Comment 14

[Paul]

I was playing around with this while I'm trying to build Thunderbird.

In one of my distrobution dirs, I created a "lib" dir, and then from that dir, ran :

for file in `find ../ -name "*.so"`;do ln -s $file . ; done 

After doing that, I was able to run mozilla-bin, without setting up the env vars.
So, if we can do something for xpinstall, and also have it working under the
build tree, I think we are in business.  

To get it working in both places, we need to modify the Makefile system, such
that, when a .so is created, a symlink to it is created from the new lib dir. 
This will fix the build tree.  Then for xpinstall, we just need to ensure that
the only symlinks that are stored in the package are the ones in the lib dir.

Thoughts/Comments?

Comment 15

[Sergei Dolgov]

Needs new take

Comment 16

[tqh]

Is there a good way to find out where/how the buildscripts create the directory structure? For instance the libs that go to moz-bin-dir (ie where firefox-bin is) we want to go to ./libs and ./add-ons depending on they are linked to the binary or loaded on demand? Is all that done by rules.mk?

Comment 17

[Mats Palmgren (inactive)]

Sorry, but BeOS support has been removed from mozilla-central.