RE: Compiling 4GL on Linux SUSE 6.4

Danny De Koster wrote > >I'am trying to port my application on a Linux machine but I have some >problems compiling my programs. >In this case he says undefined reference to `mg_error`. This mg_error >function is situated in the library1.a file. I had the same problem when porting our applications from AIX to Linux RedHat, especially when linking in archive or '.a' type files. Now I have no idea why the following procedure worked (perhaps some kind soul can enlighten us) but try changing the order in which the files are linked on the command line (or in the makefile). Try variations of the following : c4gl library1.a library2.a sources.o sources1.o -o sources.4ge c4gl library2.a library1.a sources.o sources1.o -o sources.4ge etc. Once you've figured out the sequence, you'll see it works for all of your applications (that use the same libraries) and you can automate the procedure by writing a small script to generate makefiles in that specific order for you. Now, this is obviously not the final answer but it is an immediate and practical solution to your problem and will save you oceans of time. You can always go on the 'linker option easter egg hunt' at a later stage but in the interim your application port can go forward. HTH Regards David -- A good scapegoat is almost as good as a solution. Andrew Wrote> > Some linkers keep a track of all library contents and can effectively > re-search libraries, or know that a function is available from > that library, so you can have circular references between libraries. > > Perhaps there is a linker switch you can find in the manual pages which > enables similar behaviour in the Linux linker. > > Otherwise, the only trick left is to become familiar with the circular > references and "flatten" them out by listing the libraries twice > > eg > > c4gl -o sources.4ge sources.o sources1.o library1.a library2.a > library1.a library2.a > > ad nauseum > > Codd help you if the linker likes to complain about the same > function being > seen twice in a different library...

David Conn wrote in message <94kceo$fv$1@news.xmission.com>... > >I had the same problem when porting our applications from AIX to Linux >RedHat, especially when linking in archive or '.a' type files. > >Now I have no idea why the following procedure worked (perhaps some kind >soul can enlighten us) but try changing the order in which the files are >linked on the command line (or in the makefile). > >Try variations of the following : > >c4gl library1.a library2.a sources.o sources1.o -o sources.4ge >c4gl library2.a library1.a sources.o sources1.o -o sources.4ge >etc. > Ahhh - this proves my guess that the linker looks exhaustively thru the first library then forgets about it. If your .o calls function A() in lib2, and function A() calls function B() in lib1, then the linker tries to resolve the functions like this: 1) Need to get A() from somewhere 2) Discover it in lib2 - when it starts to search lib2 3) A() calls B() so it adds B() to the needed function list 4) IF lib1 has already been examined and forgotten about, you can forget about it too... link will fail. 5) If you list lib1 AFTER lib2 then it will be found. Linkers on some platforms examine all libaries and remember discovered functions in a heirarchy, some linkers repeatedly examine the libraries over and over again (but forget the contents as they move onto the next) and some linkers just work from left to right (or right to left if you are reading this in Arabic) and these linkers are the worst if you have complex relationships between the libraries. The 3rd case can be overcome by merely listing the required libraries over and over again, so that it's got no excuse to miss the required functions, but perversly, some linkers ignore repeated mentions of libraries, and some linkers say "HEY! I've seen function A() in lib1 and now I can see function A() in lib1 so I'm going to crap-out now!" Hopefully these linkers are becoming more and more historical. If you read the manual page on your linker, you might find some linker flags which change the default behaviour to one of the nicer ones. Your only remaining task is to get those flags injected into c4gl at the right place. Look also for environment (shell) variables that influence the linker directly, or look in c4gl for variables specifically provided by Informix. I must confess that on SCO and HP we hack c4gl directly, because we always have.