2024-11-24 14:47 UTC
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002802Buildsystem[All Projects] Generalpublic2020-12-26 13:472020-12-29 20:22
ReporterEric Dodd 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformSGIOSIRIXOS Version6.5.30
Summary0002802: Adding compatibility library to CFLAGS unexpectedly changes option to be rpl_option
DescriptionIn the process of porting Netsurf to IRIX, if we add our compatibility library to CFLAGS like `-I%{_includedir}/libdicl-0.1` , some parts of the build system seem to change `option` to be `rpl_option`. This causes "unknown symbol" errors, as the build is looking for `corestring_lwc_rpl_option`.



Steps To Reproduce* Get an SGI
* Install SGUG-RSE 0.0.7 from https://github.com/sgidevnet/sgug-rse/releases/tag/v0.0.7beta
* Build and install the following packages that are not yet available as binaries:

SDL
xcb-util
xcb-util-image
xcb-util-keysyms
xcb-util-wm

* Build netsurf 3.9 from the listed wipnonautomated branch
Additional InformationWe're basing the port on the version of Netsurf in FC31, 3.9.

Patches and spec can be found here: https://github.com/sgidevnet/sgug-rse/tree/wipnonautomated/packages/netsurf .

Netsurf is likely the best chance at having a working modern browser on IRIX.

We're unable to attach a debug log, as `netsurf -v` emits whitespace but doesn't launch a window. Without -v, it does launch a window, and sometimes can be stable for whole minutes without crashing.

Yes, we're aware IRIX is a dead OS.
TagsNo tags attached.
Fixed in CI build #
Reported in CI build #
Attached Files

-Relationships
+Relationships

-Notes
John-Mark Bell

~0002306

John-Mark Bell (administrator)

2020-12-28 19:57

 The string "rpl" does not appear anywhere in the NetSurf sources:

https://github.com/netsurf-browser/netsurf/search?q=rpl

Looking at libdicl, however, yields this:

https://github.com/danielhams/dicl/blob/master/libdicl/src/repl_headers/getopt-pfx-ext.h#L46

which is included from getopt.h here:

https://github.com/danielhams/dicl/blob/master/libdicl/src/repl_headers/getopt.h#L90

and which defines __GETOPT_PREFIX here:

https://github.com/danielhams/dicl/blob/master/libdicl/src/repl_headers/getopt.h#L42

Thus, this has all the hallmarks of the global preprocessor namespace being polluted by a library header. You can probably "fix" this by "#undef option" at the top of utils/corestringlist.h (and wherever else this breakage appears).

For hopefully obvious reasons, this wouldn't be a change we would want to carry ourselves.
Eric Dodd

~0002308

Eric Dodd (reporter)

2020-12-29 19:57

 Excellent! This resolved several issues. Now it compiles with these options:

export CFLAGS="-I%{_includedir}/libdicl-0.1 -D_SGI_SOURCE -D_SGI_MP_SOURCE -D_SGI_REENTRANT_FUNCTIONS -DLIBDICL_NEED_FUNOPEN -DLIBDICL_NEED_GETOPT=1 -g -Og"
export CXXFLAGS="$CFLAGS"
export LDFLAGS="-Wl,-z,relro -Wl,-z,now $RPM_LD_FLAGS -ldicl-0.1"

However, it's still very unstable and usually refuses to display https content. My guess is I haven't yet cleared all of the namespace pollution. While we have ddd and gdb, it can't handle threads very well, which makes debugging hard.

I've attached an example screenshot (exported X session.)

Thanks for your help!
Eric Dodd

~0002309

Eric Dodd (reporter)

2020-12-29 20:22

 My apologies for the spam. I'd thought the failure was in my ancient OS not handling SSL, but it clearly renders DuckDuckGo searches.

Most importantly, the -v flag now works!

Thanks again!
+Notes

-Issue History
Date Modified Username Field Change
2020-12-26 13:47 Eric Dodd New Issue
2020-12-28 19:57 John-Mark Bell Note Added: 0002306
2020-12-29 19:57 Eric Dodd File Added: Screen Shot 2020-12-29 at 2.51.13 PM.jpg
2020-12-29 19:57 Eric Dodd Note Added: 0002308
2020-12-29 20:22 Eric Dodd File Added: Screen Shot 2020-12-29 at 3.02.21 PM.jpg
2020-12-29 20:22 Eric Dodd Note Added: 0002309
+Issue History