[gijoe77]

So far I had one program (xz-5.2.4) that has problems being compiled successfully if I included "-woff all" in the CFLAGS <URL url="https://forums.irix.cc/viewtopic.php?f=10&t=311#p2107"><LINK_TEXT text="viewtopic.php?f=10&t=311#p2107">https://forums.irix.cc/viewtopic.php?f=10&t=311#p2107</LINK_TEXT>

I now have a program (gftp 2.0.19) that runs into compiler errors if I don't include "-woff all" in the CFLAGS,
compiler returns below if I don't have "-woff all" :

Code:

cc WARNING:  -p is no longer supported, use speedshop(1) instead
cc ERROR parsing -pthread:  unknown flag

<URL url="https://forums.irix.cc/viewtopic.php?f=10&t=265&p=2083#p2083"><LINK_TEXT text="viewtopic.php?f=10&t=265&p=2083#p2083">https://forums.irix.cc/viewtopic.php?f=10&t=265&p=2083#p2083</LINK_TEXT>

anyone seen this before?

[jpstewart]

Well, the error about '-pthread' when compiling gftp is no surprise. That's a GCC compiler option that's of no use for the SGI compiler. Either something pertaining to pthreads was mis-detected during the 'configure' phase, or something is hardcoded to assume that everyone will be using GCC. Both cases are common, in my experience. I know that more than once I've had to hand-edit things to overcome those sorts of faulty assumptions.

As for the actual topic of this thread, consider this: '-woff all' turns off compiler warnings, so 'configure' for xz runs a test that should normally produce a warning on IRIX and fail, but doesn't with '-woff all', so pthread support (for example) is mis-detected by 'configure', and so the resulting Makefile doesn't work on IRIX. Thus compilation fails with '-woff all'. Conversely, in the gftp case, the Makefile is perhaps hardcoded with the wrong option (-pthread) instead of relying on 'configure', so normally compilation on IRIX would spit out the message about an unrecognized option, but '-woff all' disables that and lets the compiler keep going. Thus compilation succeeds with '-woff all' (but may result in a broken binary). IOW, things went wrong but unnoticed earlier in the xz compilation than in gftp.

So my hypothesis is that '-woff all' is just hiding a useful error message in both cases. I wouldn't use it, myself. In the gftp case, leaving the warning enabled is helpful -- even though compilation fails -- since it shows the -pthread switch being used erroneously. And in the xz case, leaving those warnings in place allowed 'configure' to properly detect things. Disabling warnings (i.e., using '-woff all') will certainly disable lots of harmless messages, but will also disable some helpful ones.

Anyway, that's my guess. I hope my convoluted logic makes sense. I'm not necessarily good at explaining my thoughts in plain English. It's easier if you just read my mind. (I'm better with code: nearly 25 years doing C on Unix!)

[gijoe77]

yeah it makes sense, it's gotta be something in the configure script, I didn't even think of that. The entire autoconfig/config/make toolset is rather confusing to me. I'm slowly working my way through the GNU make manual. I basically need to sit down with pencil and paper to follow it along and figure out what its doing - I have no problem admitting I'm not very seasoned (I'm sure it must be painfully obvious!). I don't even know x86isms/linuxisms/GCCisms when I come across them (unless they are very explicit) so that's a real curve ball sometimes too

[jpstewart]

<QUOTE author="gijoe77" post_id="2198" time="1533980571" user_id="243">

The entire autoconfig/config/make toolset is rather confusing to me. I'm slowly working my way through the GNU make manual.

Heh, I consider most of that stuff to be "read only". I can follow the logic of configure scripts to find out what's going wrong, but don't ask me to set one up! I'd rather hand-write a simple Makefile. I've always learned stuff a little bit at a time, just as much as I need to know for the current project. I found it too overwhelming to tackle all at once. But maybe that's just my learning style....

<QUOTE author="gijoe77" post_id="2198" time="1533980571" user_id="243">

I have no problem admitting I'm not very seasoned (I'm sure it must be painfully obvious!).

Obvious, yes. But not "painful". We all have to start from the beginning.

IMHO, what's important is a willingness to learn, which you've demonstrated plenty. And quite frankly, it's a lot less work for somebody like me to offer pointers and suggestions to somebody like you who is willing to do most of the work of compiling. Whether my suggestions put you on the right track or send you off on a wild goose chase is "left as an exercise for the reader", as they say. LOL. But spending 10 minutes pontificating on your problem is a lot less effort for me than spending an hour compiling/packaging stuff.

I haven't seen former Nekochan members Foetz and Canavan here yet (although maybe they're here under different names). IIRC, those two were good ones to offer porting advice and had plenty of IRIX experience. I hope they make their way here, if they haven't already. (In addition to those who are already here.)

And despite my years of experience, I stumble over problems on a regular basis and learn new stuff almost every day. Jan-Jaap's tip about the pthread functions libc and libpthread from the other day is a great example of that. So don't get discouraged if you encounter trouble. It happens to everyone. The IRIX community has usually been very supportive of one another.

As I said above, your approach and your willingness to delve into it are far more important than what you know.

<QUOTE author="gijoe77" post_id="2198" time="1533980571" user_id="243">

I don't even know x86isms/linuxisms/GCCisms when I come across them (unless they are very explicit) so that's a real curve ball sometimes too

That's the sort of stuff that comes from experience. There's no quick way to learn it.

Anyway, the point is: keep up the great work you've been doing so far!

[mrthinlysliced]

<QUOTE author="gijoe77" post_id="2198" time="1533980571" user_id="243">

The entire autoconfig/config/make toolset is rather confusing to me. I'm slowly working my way through the GNU make manual.

This may or may not help, depending on where you are on your journey of discovery .-)

The way the auto* tools hang together isn't obvious at first glance - and is related mostly to the history of how they came about coupled with a quirky language / macro system they are (mostly) implemented in.

Once you understand that "make" itself is at the core a way to specify targets and their dependencies - why the auto* tools exist starts to make a little more sense. "make" works nicely when you are building on one machine where you know in advance this header file exists, always use this library etc. If you don't know which headers exist or which libraries might be used, using "make" alone quickly becomes a pain in writing a build script in a human editable way.

My understanding of these tools is as follows:

<LIST>

• <LI>
• automake - you write a list of things (Makefile.am) you want to build and what they depend on - automake generates you makefiles for them + tracks dependencies</LI>
  
  <LI>
• autoconf - you write a bunch of things you want to discover in configure.ac - and autoconf will generate you a shell script (configure) that will execute tests for discovery and produce a C style header file with results that you can use directly in the code (e.g. #if defined(HAVE_STRTOD) ). Integrates with automake so that you can supply arguments to the "configure" script to build optional components and have those things tailor the makefiles</LI>
  
  <LI>
• libtool - The way in which static and shared libraries and binaries are built and linked depend on quirks of an individual platform (see differences between windows and *NIX) - by using special targets in automake files you can let libtool manage creating/linking/installing correctly libraries on the platform the build is being done.</LI>
  

</LIST>
It's possible to choose / use only one or more of the above tools, but for a lot of projects they use the three together (sometimes badly .-)

For autoconf projects the interesting stuff is written by developers in "configure.ac". Running configure creates a config.log, config.sh etc and if you want to modify the configure.ac you must run "autoreconf" or something similar afterwards which will recreate the "configure" script and rerun automake too.

They aren't the easiest to understand unfortunately and because they use little known tools (m4) it can be daunting.

The approach I used to learn them was to create three projects - one standalone shared library project, a second library project depending on the first and then a third project with a program that used both libraries. I'll have a hunt and see if I've still got those around, it might be educational.

Mr TS.

[gijoe77]

I found this to be very helpful! Thanks for the write up! If you could find those three projects that would be very cool! Thanks

[mrthinlysliced]

I couldn't find the old projects I had, but I'll need something like them at some point so a little bit of fiddling later - here's a couple of tarballs.

Each has the same three projects (base lib, second lib, program using them).

<LIST>

• <LI>
• daceps-initial.tar.gz - These is the kind of project a maintainer starts with - this is what a dev would write. To be able to use it, you run bootstrap.sh (often named autogen.sh or other names, name is what you choose). If you don't have autoconf/automake/libtool/pkgconfig, this one might not be too useful other than to look at it.</LI>
  <LI>
• daceps-afterbootstraps.tar.gz - Here I've run the "bootstrap.sh" script which means autoconf/automake etc have all done their magic and generated the kind of support files for the package that get distributed/released by the project. You'll be able to ./configure --prefix=BLAH, ./make, sudo ./make install (order must be libraryone, librarytwo, program).</LI>
  

</LIST>

If you don't have the tools on your SGI you can always run them on a Linux box of course (I've had them building on Irix + Linux).

Mr TS.

Something screwey with multi attachments. I'll do one here.

[mrthinlysliced]

And the second one here.

[gijoe77]

oh dang it, I didn't get a chance to grab those files - I was planning on sitting down on the weekend to look this over :( *

Can you maybe upload them to the ftp?

[Raion]

Guys,

Attachments are disabled due to issues with PHPBB code base. Please use an external host, i.e. pomf.cat or another file host to host these files.

We are looking to migrate the entire site soon, but attachments will not be retained in all likelihood.