June 12th, 2003, 04:00 PM
C++ porting issue
I have an app that was orginally developed for Mandrake 5.x and I am incharge of porting the app for use on OpenBSD 3.3.
I am getting an error when using gmake (what was designed to be used) with one class, if I remember my C terms correctly, an incldude in the /sys/timeb.h file.
During the compile this error shows up:
g++ -c -o Lupdate.o Lupdate.cpp
In file included from Lupdate.cpp:4:
/usr/include/sys/timeb.h:49: syntax error before `;'
gmake: *** [Lupdate.o] Error 1
My guess is that there is some difference in the timeb.h class either from the 5.x version of mandrake to its present version or some difference between the file on linux and BSD.
My last C++ class was about three years ago and I have used it very little since I became the database admin and asst. sys admin at our firm. All of our C++ developers learned on either Borland or MS visual C++ so I am a little up the creek here.
Any ideas or help or ideas on what the problem is would be great.
Thx in advance.
Why? Because Forms just look cooler in OS X...
Dutch, it's like German...but not!
June 14th, 2003, 07:21 AM
Unfortunately, your problem is probably a little deeper. sys/timeb.h is (as the name actually says) a system specific header file. In other words, whoever coded your application has made use of features that were specific to the original operating system and compiler.
Such things can port cleanly (eg between versions of unix) but there is no guarantee they will.
My suggestion is that you comment out the line that #include's this header file (or, if it is being #include'd from a system header, comment out the code that includes that system header). The result will probably be, when you compile again, more error messages, but those will probably help you identify the code that actually makes use of functions, constants, or types that are declared in sys/timeb.h. You will then need to work out what that code does, and modify it so it works on your new target machine with your new compiler. I suggest you wrap the modifications with something like
/* the original code */
#elif defined (MACRO_THAT_IDENTIFIES_NEw_SYSTEM)
/* your new code */
where the MACRO_ ... are macros defined by your compiler implementations. For example, a common way of identifying a GNU C++ compiler is to look for a macro called __GNUG__
June 25th, 2003, 03:54 PM
Well I removed/commented out the line and recompiled. It seems as though the system compile correctly on our test box. Now to test it out ans see what errors appear.
June 27th, 2003, 08:55 AM
You may be lucky, and a previous developer left in an extraneous #include.
Suggest you check to be sure. If you have been given test cases for functions in that particular source file, ensure they work as they're supposed to. Test the overall working of the program as best you can. Do a review of the code to see if there's anything that may have depended on the original header file.
We quickly found that the what the file did. It managed microtime functions for operating ticks so the program knew when or how long it had been since it preformed system maintance.
I was going through the ports tree to discover a RedHat Emulator. We installed the package and then went and did a retry with the orginial file, good ole cp file file.old trick, and it compiled without any errors using RH 6.2 in emulation.
Now it seems to be working fine. We will test it next week before putting it on the production boxes. Darned 4th of July holiday is messing up the plans since myself, and pretty much everyone else in the office are leaving.
learn something new everyday