Why is setting up a build environment so much work!?

[scootermaster]

Short version: I'm trying to disentangle the build environment of the Open64 compiler. Luckily, I don't really need to do anything with the compiler proper; I want to take one of the utilities that mucks with the intermediate format that the compiler produces, and change it.

So, I've managed to set up a different directory where I can compiler said tool (it has a three-include-deep makefile). And I can even copy the source directory (from the compiler source tree) into a new directory, change it, and compile it in that new directory. That works fine. And when I make a new makefile (including the old make file), and make a new entry, with nothing much more than a renamed version of the old utilities (in this case, ir_b2a to ir_poo or something), it compiles. But when I run the resultant executable (which is the same size as the normal one) it says "unrecognized command ir_poo".

I can provide more details, but I really don't get this.

 

[degibson]

This is rather curious -- what is producing the 'unrecognized command' output? Is it an executable that you compiled, or is it the shell? If it is the former, you can try grepping through the source for ir_b2a -- maybe there is a list of tools somewhere in the code?

 

[scootermaster]

Originally posted by: degibson
This is rather curious -- what is producing the 'unrecognized command' output? Is it an executable that you compiled, or is it the shell? If it is the former, you can try grepping through the source for ir_b2a -- maybe there is a list of tools somewhere in the code?

Okay, more weirdness....

When I rename the ir_poo executable to ir_b2a, it works.

So maybe it's just the shell? They both have the same permissions, the same file size, and were compiled from the same source (just renamed).

So, to recap, here's what we're doing:

I took the makefile (curiously, for where it ends up being compiled, not for where the source resides) for this utility, ir_b2a and copied it to a new directory. I tweaked some of the environment stuff to be hardcoded, to sort of removed the whole thing from the build environment. Then I added another entry to the makefile in the directory that contains the ir_b2a.cxx source, to contain a new entry ir_poo, that's just about identical (same structure, different filenames). Copied the ir_b2a.cxx file to ir_poo.cxx file. make ir_poo. It makes just file. Run ir_poo, get "unrecognized command ir_poo". Run ir_b2a, it works fine. mv ir_poo ir_b2a, and it runs fine too, so it's not a problem with the binary.

WHA?!

Googling "unrecognized command" linux, gets me all sorts of things with unrecognized command line parameters. Blarg.

Help!?

 

[degibson]

Try grepping though the source and makefiles for 'unrecognized command'. You may get lucky there. In order to figure out how to fix this, we must know what is actually producing the 'unrecognized command' output.

Also: After making ir_poo, can you run it directly from the shell, by providing the full path?

 

[scootermaster]

Originally posted by: degibson
Try grepping though the source and makefiles for 'unrecognized command'. You may get lucky there. In order to figure out how to fix this, we must know what is actually producing the 'unrecognized command' output.

Also: After making ir_poo, can you run it directly from the shell, by providing the full path?

Lord.

I'm an idiot.

AN IDIOT!

You tried to tell me, but I thought it was in the build environment, and I'd been over all the makefiles with a fine-toothed comb, and obviously knew there wasn't any "unrecognized command" statements there.

Of course, I ALSO knew that the source file (ir_a2b.cxx) spawned like three or four different applications; some of which were just symbolic links to the main one. You'd think that'd sort of imply that the main app had to have some way of differentiating what the fuck it was supposed to do. You know, like, maybe what the application was called?

You nailed it. One big if chain based on argv[0]. So, problem fixed. And I now, more or less, have a separate build environment where I can alter this tool as I see fit. This is good! May as well just give me my Ph.D. right now!

Onto the next question: This isn't vital, but when the source file is compiled, both in the native compiler build environment and in my own new directory, it pulls in a bunch of .o files (not to mention .d files) and sticks them where the executable goes (in the native build environment) or where the executable and the source go (my new one). It's a cleanliness issue, but is there some [easy/obvious] way of tinkering with the makefiles so this doesn't happen? These files, and the sources that make them aren't likely to [ever] change, so there's no real harm in sticking them someplace else, leaving my directory clean for my own source files.