I have some C++ code that was working. I was working on an older version of Ubuntu and the code worked fine. My system ran an update and now I cannot compile the code. Since the computer was old I took the opportunity to attempt to compile the code on a different machine. I cannot go back to the old machine now, since it has completely died.

I am not sure if the problem is that the current version of Boost has changed so my code is no longer valid, or if is a problem of not linking to the correct library.

There was a line in the make file before that linked to the library -lboost_program_options-gcc43-mt-1_35

With a newer version of boost I cannot find a corresponding file (that has a specific version of gcc for the version of boost) the closest library I can find is
-lboost_program_options-mt

If I link to this file I get a large error output due to "Undefined symbols".

I have tried to install the version of boost that I was previously using (1.35) but for some reason I cannot get it to install properly (I tried on Ubuntu 10.10 32 and 64 bit and on OS X).

I also have tried to use g++ 4.3 (I am assuming I used g++ 4.3 on the old computer because of the name of the library I was linking to), thinking maybe my code is not working due to a change in the language, but this results in the same error.

I am not familiar enough with development with Boost to know if their have been significant changes in the library (I am only using it because I am modifying someone else code). Is anyone aware of how the program-options library may have changed since 1.35?

I have attached a file containing the error, if this is help to anyone. I am not much of a c++ programmer, so it does not make any sense to me (thank you school for only teaching me Python, Java, Matlab, and basic C programming ).

If anyone has any insight on what a problem might be, or what I should try to do to fix it please let me know. If you need more information ask and hopefully I can provide it.


Thanks! (Sorry for the long post, I was trying to be thorough).

Attached Files

error_file.txt (24.1 KB, 25 views)

cd to the directory where the libboost libraries live (/usr/lib64 on my
slackware64 box) and try the following:
For me the bemoaned symbols seem to reside in



Cheers,
Tink

I was able to get the output, and the ones with the symbols were
libboost_program_files.a
libboost_program_files-mt.a

Does it matter that these are .a files and not .so? I tried to try the compilation with the -static tag but that did not seem to help.

Anyway, I was wrong in my original post. The error I posted was the error from my Mac. From Ubuntu, the error looked similar at a glance, but once I looked closer I realized the only problem was an architecture problem caused by an error in my makefile was not deleting an old .o file from the machine where I grabbed the code. Once I corrected this the code compiles and runs fine in Ubuntu (and even in Cygwin).

I still cannot get it to work on my Mac, but I am able to use the code, so I am not positive if it would be the best to spend more time trying to get it to run properly there.

Thank you for your help Tink.

This seems like an odd statement:
Did you not mean to use:

I'd think so ... one is for static linkage, the other for dynamic.

Maybe you didn't build boost on the Mac with dynamic link support?
Or the dynamically linkable files live somewhere else?



Cheers,
Tink

@dwhitney67
I thought I had read somewhere that if I give an absolute path to a library I was supposed to use the form that I did. I guess I either misread the information or the information was wrong, because that seems to make a big difference in whether the code will compile or not!

@Tinkster
I did read elsewhere about someone having a similar problem (and they only had one of the .a and .so) and it was because they only downloaded librarypackage and not librarypackage-devel however using macports on the Mac didn't seem to give me an option of which of the two I should install, there was only one package. However, it does seem to work when I use the dwhitney67 suggestion, so I guess I don't need the .so for what I am doing.

Thank you both for your help.

It now works on three different types of systems (Ubuntu, cygwin, and Mac) so I can develop in my OS of choice and then give it to my coworkers to use on their Macs or Windows machines later.

When you use the approach I outlined, you are using the .so (shared object) library, if it is present on the system; otherwise the static library is used. If you want to specifically use the static library (that is, the one with the .a extension), then you would precede the -l (lowercase ell) option with the -static option. For example:
There are advantages and disadvantages to using the static library; the advantage is that the person(s) using the application do not require the need to install the runtime packages (e.g. boost) so that the shared-object library can be referenced. The disadvantage, depending on one's thoughts, is that the application will be "huge" in size compared to one that uses shared object libraries.