libjpeg-turbo version

IRIX/Nekoware development, porting and related topics.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

libjpeg-turbo version

Unread postby hamei » Mon Mar 02, 2015 8:15 pm

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 ...
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

robespierre
Posts: 1551
Joined: Mon Sep 12, 2011 2:28 pm
Location: Boston

Re: libjpeg-turbo version

Unread postby robespierre » Mon Mar 02, 2015 8:41 pm

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.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:

User avatar
jan-jaap
Donor
Donor
Posts: 4881
Joined: Thu Jun 17, 2004 11:35 am
Location: Wijchen, The Netherlands
Contact:

Re: libjpeg-turbo version

Unread postby jan-jaap » Tue Mar 03, 2015 12:08 am

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 :)
:PI: :Indigo: :Indigo: :Indy: :Indy: :Indy: :Indigo2: :Indigo2: :Indigo2IMP: :Octane: :Octane2: :O2: :O2+: Image :Fuel: :Tezro: :4D70G: :Skywriter: :PWRSeries: :Crimson: :ChallengeL: :Onyx: :O200: :Onyx2: :O3x02L:
To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. (IRIS 4D/70 Superworkstation Technical Report)

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: libjpeg-turbo version

Unread postby hamei » Tue Mar 03, 2015 3:32 am

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 ...
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered


Return to “SGI: Development”

Who is online

Users browsing this forum: No registered users and 4 guests