libjsdbg_static

[dybal]

Greetings!

I tried to compile the devel version of trunk and it failed at linking time, complaining that jsdbg_static.a wasn't found.

There is a libjs_static.a at depsLinux-deps/x86_64/mozilla fom the oolite/oolite-linux-dependencies project in github, but the libjsdbg_static.a is missing...

I managed to build it from spiderMonkey source, but it wasn't easy filling the blanks... if the debug static version of libjs was there it would enable more people to build oolite from source... perhaps someone with access to the machine that builds the nighlies could upload it?

[Getafix]

Hi dybal,
adding two libjsdbg_static.a (32bit and 64bit) would augment the Oolite source-code size by 140MB. This would also impact Windows and macOS developers.

The other option would be to link to the same JS library even if Oolite debug target is selected. This could be either done by editing the GNUMakefile

Code: Select all

    ifeq ($(debug),yes)
#        LIBJS                    = jsdbg_static
         LIBJS                    = js_static
# By default we don't share the debug version of JS library
# If you want to debug into JS, ensure a libjsdbg_static.a exists into $(LIBJS_DIR)
    else
        LIBJS                    = js_static
    endif

or by delivering one more instance of libjs_static.a (that is much shorter) having libjsdbg_static.a as filename.
Both these options are not clear and they are actually hiding from the developer the fact that a non-debug libjs is used.

The last option could be to use the pre-compiled library, but to debug build JS from source when Oolite debug targets are selected. However, developers from various Linux distros were reporting that they had trouble building JS from source. This was adding clutter to our support efforts and given that we are short of support hands, we dropped this option.

Having run out of options, we preferred to let the developer look into Makefile and GNUmakefile to select one of the aforementioned options.

Anyhow, I will re-examine this case with the Oolite Elders.

[dybal]

Thanks for the answer, Getafix!

The linker expects libjsdbg_static.a in deps/Linux-deps/x86_64/mozilla

That's in the OoliteProject/oolite-linux-dependencies submodule, another project in github, downloaded by running git submodule update --init after git cloning the Oolite Project.

There is already the libjs_static.a at that place in the oolite-linux-dependencies submodule, with 5.6M, and the libjsdbg_static.a I build has "only" 73M.

Including libjsdbg_static.a would increase the download, but only if git submodule update --init is used as suggested in the docs (don't remember exactly which one), but it could be used specifying the submodules to initialize.

I suggest creating a makefile target to initialize the submodules, and using the same environment variables used to know what platform to build to choose the submodules to initialize.

It took me a while to find out how to build that lib... and another while to figure out that I had to move it manually to the correct location once built...

Copying the standard library would not break DebugConsole?

[Getafix]

...and the libjsdbg_static.a I build has "only" 73M.

Yes, but in the same submodule you get both x86 and x86_64 dependencies. This adds up to ~140MB.

Including libjsdbg_static.a would increase the download, but only if git submodule update --init is used as suggested in the docs (don't remember exactly which one), but it could be used specifying the submodules to initialize.

I'm looking into our options and I'll come back on this suggestion.

It took me a while to find out how to build that lib... and another while to figure out that I had to move it manually to the correct location once built...

I really understand, and accept my apologies on that matter!

Copying the standard library would not break DebugConsole?

Actually copying the standard library (or editing GNUmakefile to use the standard library) breaks the linker, so no Oolite binary is produced in these scenarios. I just tested it. As far as it concerns the DebugConsole, you don't need a debug target to use the DebugConsole.

Have you found an added value in using the debug target, that you actually took advantage of, and that you don't get from the [deps-]release or [deps-]release-snapshot targets?

[dybal]

...and the libjsdbg_static.a I build has "only" 73M.

Yes, but in the same submodule you get both x86 and x86_64 dependencies. This adds up to ~140MB.

True, I didn't think about that...

It took me a while to find out how to build that lib... and another while to figure out that I had to move it manually to the correct location once built...

I really understand, and accept my apologies on that matter!

Don't worry, I'm not really bitching about it, when I started this topic I was a complete Oolite rookie (not that I'm that much less ignorant and näive now )... the real issue is that it creates a high barrier for people starting in the dark side: you clone the oolite repo, initialize the submodules, and then run make -f Makefile and get a linker error pointing to libjsdbg_static:

Code: Select all

 Compiling file src/Core/OOTrumble.m ...
 Compiling file src/Core/Universe.m ...
 Linking objc_program oolite ...
/usr/bin/ld: cannot find -ljsdbg_static
collect2: error: ld returned 1 exit status
/usr/share/GNUstep/Makefiles/Instance/objc.make:79: recipe for target 'obj.spk.dbg/oolite' failed
make[4]: *** [obj.spk.dbg/oolite] Error 1
/usr/share/GNUstep/Makefiles/Instance/objc.make:64: recipe for target 'internal-objc_program-all_' failed
make[3]: *** [internal-objc_program-all_] Error 2
/usr/share/GNUstep/Makefiles/Master/rules.make:297: recipe for target 'oolite.all.objc-program.variables' failed
make[2]: *** [oolite.all.objc-program.variables] Error 2
/usr/share/GNUstep/Makefiles/Master/objc.make:36: recipe for target 'internal-all' failed
make[1]: *** [internal-all] Error 2
make[1]: Leaving directory '/home/dybal/pessoal/oolite/core-game/oolite-local'
Makefile:73: recipe for target 'debug' failed
make: *** [debug] Error 2

Then you start digging about that lib and most info you find on how to build it is dated... I think most people just give up.

Have you found an added value in using the debug target, that you actually took advantage of, and that you don't get from the [deps-]release or [deps-]release-snapshot targets?

You got me there... I don't really know what the debug target brings to the table... I assumed (my ignorance and naivety showing again... ) the DebugConsole depended on it.

I just built the pkg-posix-nightly target without libjsdbg_static.a and it supports debug console, profiling, and shows the filename and line number for exceptions, so I think I don't really need the debug library...

Perhaps taking the debug from the all make target, changing the readme from "run make -f Makefile" to "run make -f Makefile all" and adding instructions about setting GNUSTEP_HOST_CPU and running git submodules update --init before "making all" would be enough? That would cover the things I had trouble with when I started...

[Getafix]

If you are just interested in playing Oolite while experimenting with OXP development and Debug Console, I strongly suggest you get the OXP Developer release installer from http://oolite.org/download/ (check out the "OXP Developer release" download section).
The latest stable release Oolite v1.90 has gone live some ten days ago.
The installer is safe and it has been thoroughly tested in all the major Linux distros for more than 9 years. Go with the "home directory" installation option.

If you insist going with the "build your own Oolite" approach, then I suggest you do the following for a clean start.

Code: Select all

$ make -f Makefile distclean   # this will clean all Oolite object files, cleaning the Mozilla JS build objects too.
$ rm deps/Linux-deps/x86_64/mozilla/libjsdbg_static.a    # you don't need this library to build an Oolite target 
                                                         # having Debug Console capabilities.
$ make -f Makefile release     # this will build Oolite OXP Developer release, enabling the extra features necessary 
                               # to an OXP Developer (e.g. Debug OXP and Debug Console support, etc.).

[Getafix]

A new code commit has just been pushed to the OoliteProject/oolite repository, updating the 'Makefile' file, in an attempt to address the confusion created by having the 'debug' target as default.

@dybal - Thank you for bringing this to our attention.