SGI: Development

libjpeg-turbo version

hamei
From over the rainbow
Who joined Feb. 24, 2004, 4:10 p.m.

Wrote the following at March 2, 2015, 8:15 p.m...

The libjpeg-turbo in /beta is 1.31, currently version is 1.4 and there are some (claimed) improvements and additions in the newer version.

It builds and installs fine, but when you try to run anything,

Fatal Error: Cannot find object libjpeg.so with version 62.0 in any of the filenames /usr/nekoware/lib/libjpeg.so:/work/pango-1.28.4/pango/.libs/libjpeg.so:/opt/build/pango-1.12.4/pango/.libs/libjpeg.so:/usr/nekoware//lib/libjpeg.so:/usr/people/lwhite/glib-2.26.1/glib/.libs/libjpeg.so:/usr/local/lib/libjpeg.so:/usr/lib32/libjpeg.so:/usr/lib32/internal/libjpeg.so:/lib32/libjpeg.so:/opt/lib32/libjpeg.so:

Okay, this is a known problem, according to the BUILDING.txt the default is v 62.1

By default, {version} is 62.1.0, 7.1.0, or 8.0.2, depending on whether
libjpeg v6b (default), v7, or v8 emulation is enabled.

so set JPEG_LIB_VERSION=62 as an environment variable and try again.

Same result. It's supposed to default to 62 but ? Let's look in libjpeg.la

Code: Select all


# libjpeg.la - a libtool library file


# Generated by ltmain.sh - GNU libtool 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)


#


# Please DO NOT delete this file!


# It is necessary for linking the library.




# The name that we can dlopen(3).


dlname='libjpeg.so.63'




# Names of this library.


library_names='libjpeg.so.63.0 libjpeg.so.63 libjpeg.so libjpeg.so'




# The name of the static archive.


old_library='libjpeg.a'




# Libraries that this one depends upon.


dependency_libs=' -L/usr/nekoware/lib -L/usr/lib32'




# Version information for libjpeg.


current=63


age=1


revision=0




# Is this an already installed library?


installed=yes




# Should we warn about portability when linking against -modules?


shouldnotlink=no




# Files to dlopen/dlpreopen


dlopen=''


dlpreopen=''




# Directory that this library needs to be installed in:


libdir='/usr/nekoware/lib'


~

Ouch. But ...

Code: Select all


urchin 10% cd /usr/nekoware/lib


urchin 11% ls


...


libjpeg.a


libjpeg.la


libjpeg.so


libjpeg.so.62


libjpeg.so.63


libjpeg.so.63.0


...

Hmm. Okay, punt : look at the release notes for the working libjpeg :

./configure '--prefix=/usr/nekoware' --mandir=/usr/nekoware/man 'CC=/usr/bin/c99' 'CFLAGS= -diag_suppress 3649 -diag_error 1035 -DIP32 -DIRIX -O3 -n32 -mips4 -OPT:Olimit=0:roundoff=3 -TARG:platform=IP27:proc=r10000 -L/usr/nekoware/lib -L/usr/local/lib -L/usr/lib32 -I/usr/nekoware/include ' 'CPPFLAGS= -diag_suppress 3649 -diag_error 1035 -DIP32 -DIRIX -I/usr/nekoware/include/freetype2 -I/usr/nekoware/include/ -I/usr/nekoware/include/SDL ' 'CXXFLAGS= -ptused -diag_suppress 3649 -diag_error 1035 -DIP32 -DIRIX -O3 -n32 -mips4 -OPT:Olimit=0:roundoff=3 -TARG:platform=IP27:proc=r10000 -I/usr/nekoware/include ' 'CXX=/usr/bin/CC' 'LDFLAGS= -rpath /usr/nekoware/lib -L/usr/nekoware/lib -L/usr/lib32/mips4 -L/usr/local/lib -L/usr/lib32 -lfastm -lm '

so far so good, configures and builds okay ... then

libjpeg.so.63.0 manually relinked to get the -set_version right:

/usr/bin/ld -n32 -shared .libs/jcapimin.o .libs/jcapistd.o .libs/jccoefct.o .libs/jccolor.o .libs/jcdctmgr.o .libs/jchuff.o .libs/jcinit.o .libs/jcmainct.o .libs/jcmarker.o .libs/jcmaster.o .libs/jcomapi.o .libs/jcparam.o .libs/jcphuff.o .libs/jcprepct.o .libs/jcsample.o .libs/jctrans.o .libs/jdapimin.o .libs/jdapistd.o .libs/jdatadst.o .libs/jdatasrc.o .libs/jdcoefct.o .libs/jdcolor.o .libs/jddctmgr.o .libs/jdhuff.o .libs/jdinput.o .libs/jdmainct.o .libs/jdmarker.o .libs/jdmaster.o .libs/jdmerge.o .libs/jdphuff.o .libs/jdpostct.o .libs/jdsample.o .libs/jdtrans.o .libs/jerror.o .libs/jfdctflt.o .libs/jfdctfst.o .libs/jfdctint.o .libs/jidctflt.o .libs/jidctfst.o .libs/jidctint.o .libs/jidctred.o .libs/jquant1.o .libs/jquant2.o .libs/jutils.o .libs/jmemmgr.o .libs/jmemnobs.o .libs/jaricom.o .libs/jcarith.o .libs/jdarith.o .libs/jsimd_none.o -L/usr/nekoware/lib -L/usr/local/lib -L/usr/lib32 -L/usr/lib32/mips4 -lfastm -lm -lc -soname libjpeg.so.63 -set_version sgi63.0:sgi62.0:63.0:62.0 -update_registry .libs/so_locations -o .libs/libjpeg.so.63.0

"Line length is limited to 1024 characters" (Didn't quote it, sorry)

So, split that command up and ran it in pieces, seemed to work, installed the library okay but running an app against it (in this case Graphics Magick) segfaulted. And so did Pho.

So gmake distcleaned and rebuilt without the manual relinking, segfaults went away but we're back to "cannot find libjpeg" etc etc.

I rooted around in the configure file, it does set the version to 62.1 when apparently my applications are looking for 62.0, but do these minor minor versions cause that ? I thought that within major versions applications were not so picky ?

btw, in case a computer science student who loves MIPS and SGI is looking for a task,

Code: Select all


checking if we have SIMD optimisations for cpu type... yes (mips)


checking if the assembler is GNU-compatible and can be used... no


configure: WARNING: SIMD support can't be enabled.  Performance will suffer.

so MIPS supports simd but the gnu assembler does not ...

he said a girl named Patches was found ...

robespierre
From Boston
Who joined Sept. 12, 2011, 2:28 p.m.

Wrote the following at March 2, 2015, 8:41 p.m...

do any of the R10K/R12K/R14K processors actually implement MDMX? I didn't think so. Those were the SGI SIMD extensions, but their implementations (code named H1 and H2) were cancelled in the shakeup that was happening around Itanic.

jan-jaap
From Wijchen, The Netherlands
Who joined June 17, 2004, 11:35 a.m.

Wrote the following at March 3, 2015, 12:08 a.m...

hamei wrote: so MIPS supports simd but the gnu assembler does not ...

SIMD extensions to the MIPS ISA exist , and the GNU assembler has supported them for more than a decade.

robespierre wrote: do any of the R10K/R12K/R14K processors actually implement MDMX? I didn't think so. Those were the SGI SIMD extensions, but their implementations (code named H1 and H2) were cancelled in the shakeup that was happening around Itanic.

And that's why GCC won't enable SIMD/MDMX code generation

Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum : almost every MIPS/IRIX system.
Wanted : GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

hamei
From over the rainbow
Who joined Feb. 24, 2004, 4:10 p.m.

Wrote the following at March 3, 2015, 3:32 a.m...

robespierre wrote: do any of the R10K/R12K/R14K processors actually implement MDMX? I didn't think so. Those were the SGI SIMD extensions, but their implementations (code named H1 and H2) were cancelled in the shakeup that was happening around Itanic.

You guys are correct ... stupid me, believing a computer company :oops:

SGI, while pissing away billions of dollars on their way to bankruptcy twice, in 1996 wrote: MIPS MDMX, one of several MIPS Application Specific ExtensionsTM introduced today, is separate from but compatible with MIPS IV and newer instruction sets. The MDMX code features an extended 192-bit accumulator, giving a MIPS processor true on-chip high performance digital signal processing (DSP) capabilities. The high performance DSP capabilities are important for on-chip real-time video decompression, digital audio surround sound (e.g. Dolby AC-3), and data compression (e.g. fax modem). MIPS MDMX code offers twice the DSP efficiency of other SIMD architectures, better memory performance and more efficient register use.

Anyway, beat this around some today, the release notes for both current and beta versions leave something to be desired and canavan's site is inacessible (did he hurt the feelings of the Chinese people ?) ... anyone still have the canavan tardist ? hoping there's some clues in there ...

he said a girl named Patches was found ...

hamei
From over the rainbow
Who joined Feb. 24, 2004, 4:10 p.m.

Wrote the following at March 4, 2015, 7:03 a.m...

Okay, got some help from a professional : Using the release notes from the beta version that no one else has bothered to test, it is possible to build a libjpeg-turbo v 1.4. You just need to be smarter than me.

The problem is with the versioning skills of libtool, way over my head but the solution in the release notes should fix the problem.

Tested with graphics magick, pho and a couple other programs, it seems to work very well.

good night and good luck.

he said a girl named Patches was found ...