danielhams / didbs Goto Github PK

Spotted by thor, unintentional bash being picked up.

With the "libelf" package in place for rpm, make now pulls it in during "configure" due to some misguided look for it under solaris.

Deactivate it for 0.1.8 by passing appropriate ac_cv_conv thing to disable during configure.

The new didbs hashing shouldn't take into account the DIDBS_JOBS=X from the defaultenv.vars

Move this out of there and don't use wherever it is as part of a hash computation.

Currently the tests don't run at all and I'm not entirely sure why (maybe /bin/sh hardcoded path, unclear)

simple example, just compile a c file a variable declared like this:

__thread int a=0;

Unclear at the moment if this problem is coming from inside gcc or is binutils related.

gcc should be using emutls - so shouldn't emit thread local storage references in the assembly (if I've understood correctly).

The gcc compilers in a "mips3" and a "mips4" release are indeed themselves the correct isa - but their "default output" mode isn't what would be expected.

Looks like under certain cases the mips4 compiler spits out mips4 asm - but then the assembler refuses to compile it as it consider mips4 instructions unsupported.

Can be worked around for the moment by explicitly adding -mips4 or -mips3 in your CFLAGS/LDFLAGS.

Maybe look into an older binutils and work out at what point that stopped working, see if it can be brought forwards.

Use the config.sh previously created + ensure libperl.so created + all tests passing.

Simple C exhibiting the problem:

https://gist.github.com/danielhams/ac9848aeaf3b5faca0d27c8348218aeb

Currently testing older gcc versions:

4.8.2 == OK
4.9.2 == NOK

Unsure where this is coming from, but building these projects ends up launching hundreds of sub-processes way beyond the job limit provided to make -j 3.

Possibly multi-IP related, unclear at the moment.

Seem while attempting to fetch perl from ftp.cpan.org .

Courtesy of thor:

The release ball of 0.1.7 has a wget that truncates Host: headers during redirects.

Can be worked around by editing the scripts/wgethelper.sh - commenting out the wget line and adding similar but using curl -s -L -O $SOURCEURL || exit -1

Proper fix will be in 0.1.8.

Unsure if this should actually work or not.

e.g. "checking if gcc static flag -static works ... result: no"

But the output indicates a warning from ld - not necessarily that this doesn't work.

"ld: warning: linking abicalls files with non-abicalls files".

Needs a standalone test to see if this is actually working, and whether ld should be tweaked to stop emitting the warning.

Needs fixing in the patches and rebuilding (Edit. punted from 0.1.1, more pressing changes + bugs to fix for now).

Needs a meta package that will pull down the latest ones and put them in an appropriate place.

It's a "post autoreconf" patch which is massive. Maybe move back to autoreconf in the configuration stage instead of the patch.

Logs of the failing build.

Probably due to config.sh newer than config.h.

A little touch in after patching/config changes will maybe help (or re-run of config.sh).

Noticed by thor - the install phase assumes there wasn't a previous install so the mv will fail.

Patched, will be in 0.1.6.

Mistake in the 0.1.9 didbs tarball build means you might get references to a missing "libunistring.so" library.

There is a second mini tarball that contains this missing library and docs here that should be extracted at /usr/didbs like a regular tarball.

https://github.com/danielhams/didbs/releases/download/0.1.9/usr-didbs-0.1.9-n32m3gcc-unistringpatch.tar.gz

Due to the usual lib/lib32 madness, looks like the libtool linker files ".la" reference the "lib32" that gcc thinks it's installed stuff in, then I move them into the "lib" directory.

Can be manually fixed by editing the gbs*_*/lib/ "libstdc++.la" and "libsupc++.la" files (and maybe some others in there too).

This should properly be fixed by installing all n32 libraries in "lib32" subdirectories - but that's a large job and not done easily.

_rld_new_interface, glNewList.

Basically it seems that for certain symbols the IRIX ld will happily allow them to be undefined during the linking stage - but those same symbols are currently flagged as missing by binutils ld.

Somewhere inside binutils it's not correctly noticing the "don't error if this is missing" flag I've previously seen somewhere.

To be checked.

Things that need to be rebuilt afterwards:

make (maybe bash)
findutils,
emacs
binutils
libtool
perl(? probably this won't help)

Can be fixed by altering the scripts/patchhelper.sh

Change $DPATCH to patch.

Occasionally make is failing due to "duping jobs pipe".

It possibly open file limit or some other issue. Needs deeper investigation, might be related to IRIX select not working quite exactly like regular select.

Courtesy thor:

The didbs build option of "gcc mips4 n32" is missing some needed configuration (notably openssl).

The "development" branch contains the needed additional patch tweak for this to work.

Will be in 0.1.8.