SGI: Development

okay, sports fans ... xpaint was a surprise, it seems quite useful. The Athena scroll bars are not lovely but otherwise, it's maybe as good as Photoshop 3 ?

Anyway, the biggest flaw with it is, the two most common graphics formats are not supported in 2.1.1 Luckily (maybe) other people have continued with xpaint, so newer versions will work on jpegs and png's without conversion.

Looking through the release notes, lots of things fixed (and some screwed up) along the way but at 2.8.16 they forced inclusion of fontconfig. So I figured I'd try 2.8.15. Maybe can butcher the newer ones to get rid of that but for now, this'd be okay.

Everything went lovely until

I think this is a key press ? Several C files include this as well as XK_UP, XK_LEFT, &c &c.

edit: Okay, "fixed" the above by putting

#include < X11/keysym.h >
#include < X11/keysymdef.h >

in the Fatbitsthingy.c file and all the others with similar code. Is that correct ?

This next one looks to be less cooperative tho



One would think this type of thing would be universal in the language, independent of the compiler ?

hamei wrote: how to fix ?

Looks like an issue similar to the one we had when getting the newer Ted to compile. Can't help with solving though as I'm still relearning how to press the power switch on redbox .

Link to the source code? Browsing the CVS repo of the version at http://sf-xpaint.cvs.sourceforge.net/ there is no file fileBrowser.c, that I can see...

vishnu wrote: Link to the source code? Browsing the CVS repo of the version at http://sf-xpaint.cvs.sourceforge.net/ there is no file fileBrowser.c, that I can see...

Here ya go ...


This is 2.8.15, not what's in cvs. They went kinda Looney after 2.8.15. I'm thinking maybe can backport the good parts (if there are any) from the newer one later on. But first have to get it to build ....

this'd be pretty hot in Irix Motif (hint hint )

the code is using an incompatible definition of index(), which is an obsolete pre-ANSI C89 definition.
replace it with strchr().

robespierre wrote: the code is using an incompatible definition of index(), which is an obsolete pre-ANSI C89 definition.
replace it with strchr().

Mercy buckets, M. Liberté, Egalité, Fraternité ! Caught about 57 fish with that one. For a feature that was obsoleted before 1989 there sure were a lot of them

Beat my way through a bunch of little stuff, it builds all the objects now.

Alas, linking. I hate linkers It seems that everything involved with png's is unresolved. I really don't want to wade into this swamp but ... any hints on solving linker problems ?

"Unresolved text symbol first referenced by ..."

Sometimes I hate computers.

hamei wrote: It seems that everything involved with png's is unresolved. I really don't want to wade into this swamp but ... any hints on solving linker problems ?

"Unresolved text symbol first referenced by ..."

does the link line have -lpng ?

foetz wrote: does the link line have -lpng ?

And is it after whatever files are causing the errors about unresolved symbols?

GNU tools let you get sloppy and list libraries and object files in any order. The GNU linker doesn't care. The IRIX linker, on the other hand, will only use libraries to satisfy previously unresolved symbols; it's much pickier about order. So 'ld -lpng foo.o' will work with GNU ld while IRIX would have unresolved symbols, requiring 'ld foo.o -lpng' instead.

It gets tricky when there are circular references between libraries (sometimes having to specify a library multiple times), so the GNU extension makes sense. But it also causes problems like this if the Makefile assumes libraries and objects can be in any order.

jpstewart wrote:

foetz wrote: does the link line have -lpng ?

And is it after whatever files are causing the errors about unresolved symbols?

I did fiddle around with this a little, so (hopefully) the most basic of errors is not a factor ?

About -lpng,

This is the result with that directive ...

That's abbreviated, there's a bunch more.

If I move -lpng to or towards the end I can get a bunch more It appears the main problem is in librw.a but that should be using the png library ?

This is what's in librw.a

I've got the general idea that everything listed in here must be referenced earlier but the paractical aspect of how-to-find that, I'm sadly lacking

Also, the whole Makefile thingy with this program is kind of weird. It seems to be kind of a mix of the imake system and the configure system. I believe configure is calling imake, sort of. It's weird.

(Sorry for the delay, I've been swamped lately.)

The link line looks a little odd, especially the inclusion of -L/usr/lib for an n32 binary. It's also odd to use -nostdlib (which tells the linker not to look in the standard library locations) followed by two -L options which explicitly name those default locations. Off hand I'm not sure if the -L locations might only apply to the libraries specified after it, in which case it's looking at the wrong libpng.so.

I wonder: was there an error/warning earlier in the output about an incompatible ABI type? The linker might be finding the unusable o32 /usr/lib/libpng.so and ignoring /usr/lib32/libpng.so with those settings.

As a first guess, try leaving out all of the -L options except -Lrw, and leave out -nostdlib.

It might also be an issue of combining static and dynamic libraries. Were there any messages about a non-existent libpng .a ? If so, try adding -dynamic after -mips3.

jpstewart wrote: try adding -dynamic after -mips3.

it's "-B dynamic"

jpstewart wrote: (Sorry for the delay, I've been swamped lately.)

Ees no problem, when you're getting free help, beggars can't be choosers

The link line looks a little odd,

It looks to me like this weird-ass configure script is just setting some paths, then calling imake to create the Makefile ...

As a first guess, try leaving out all of the -L options except -Lrw, and leave out -nostdlib.

Tried that in the vain hope this would be easy but alas ...

A few evenings with techpubs (did you know Aspirin is like $5 a bottle now ?) and a lot of grunt work ... to recap :

1) 2.8.15 is the last version before the Guys that'r l33t to m33t jammed in fontconfig and other noncompismentis stuff. So for the moment, 2.8.15 is what we're trying

2) Went through all the configuration files and Makefiles and quadruple-checked or changed every path and/or feature that we don't have. Changed to mips4 and -O3. What the heck.

3) added the < X11/keysim.h > and < X11/keysimdef.h > includes to

fatBitsEdit.c
menu.c
operation.c
pattern.c

(How does this kind of basic error exist for twenty years ?)

4) Changed the "index" operators to "strchr" per robespierre in

filebrowser.c
print.c
brushOp.c

in 6 or 8 places

So now it finally builds all the object files. Yay.

When it crashed linking, pulled the crap that JP referred to and ran the link line manually. Used the warnings to get rid of some more errors.

Finally, we're at this point - only four failures --



these don't seem nearly as arcane as the earlier errors. The "print.o" failure is new but all the others are the same librw problem as before, just more rational ones.

So I probably have this wrong but ... the linker combines all the object files into a complete executable. The MIPSPro linker needs to have all the references defined before it can use them. Order counts. So wherever "TestPNG" is defined needs to come in the link line before it gets to librw, is that correct ?

Seems like that should be easy but so far I have not been successful

In case anyone outside the Asylum is wondering why I would bother, this program seems pretty good. It's actually nicer to use than PhotoShop* (personal opinion). It is not impossible to convert png's or jpegs to rgb first but would be nice if one didn't have to. It's pretty nice. Really.

* Inspired me to drag out the Intuous2 and install the Wackem driver. I tried Eclipse, Amazon Paint, PhotoShop and Illustrator. Illustrator was the only one that used the pressure or tilt pen features. And I don't especially like Illustrator. It's possible that the built-in Irix tablet driver is just as good as the Wackem one for 99 44/100 % Irix uses.

Back to the linking problem ... any nuts-and-bolts suggestions ? What am I doing wrong here ?

I just woke up, but I think that the ld argument list is actually reversed, objects you need symbols from should come AFTER the object that needs them.

Libpng has traditional C function names, i.e. png_foo, so those aren't from libpng, they're likely internal to the program (does ld need objects in an archive to be in order?) and basename is found in libc unless they're clobbering the standard names.

duck wrote: I just woke up, but I think that the ld argument list is actually reversed, objects you need symbols from should come AFTER the object that needs them.

Oh. That'd explain some things ...

Libpng has traditional C function names, i.e. png_foo, so those aren't from libpng, they're likely internal to the program

The libread-write thingy looks to be the cuplrit in a lot of this ...

Almost excited myself, the help for 2.1.1 says it can read jpegs -- but it doesn't work. Back to the salt mines. But due to fiddling with this thing I did discover xwd and xwud. That's pretty neat

Graphics Magick displays xwd correctly, this program displays something but it's hard to tell what it is, while xwud displays the correct graphic except way too dark.

Intresting.

basename is found in libc unless they're clobbering the standard names.

Nothing would surprise me right now ... this thing is "unusual".

I'll be back ...

It might be an issue of circular references. It's complaining about unresolved symbols in librw.a, while those same symbols (at least the PNG-related ones) are defined elsewhere in librw.a.

So add a second instance of -lrw to the end of the link line (keeping whatever is already there) and see where that gets you.