Go Back   DaemonForums > Miscellaneous > Programming

Programming C, bash, Python, Perl, PHP, Java, you name it.

Thread Tools Display Modes
Prev Previous Post   Next Post Next
  #1   (View Single Post)  
Old 18th January 2010
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
Join Date: May 2008
Location: USofA
Posts: 1,546
Default Linker errors when combining shared modules into an app as static libs

The source code is laid out in a pretty simple way:

          source for module
    source for wrapper

The modules consist of two types: application and shared code. All source files are compiled into object files (source.o / source.obj), then object files shared between applications are archived into a static library (libmodule.a / module.lib). One exception is a module that's meant to be a shared library (project.so / project.dll), shared between applications, and using the static libraries as needed. Built files go into build/os.arch/config/module/, with static libs and applications in build/os.arch/config/. The same organization is being used on FreeBSD (GCC) and Windows (Microsoft's compiler).

On Windows, the applications (and infact entire project) build successfully by linking the applications object files and the static libraries together with any dependent import libraries (for .dll's). Visual C++s linker is perfectly happy to grab up the static libs, import libs, and object files.

When I build on FreeBSD however, attempting to link the applications object files, the static libraries, and the dependent shared libraries, things go bananas over an inter module relationship:

-------------- Build: Release for FreeBSD x86 in client ---------------

gcc -Wall -msse -msse2 -DIS_UNIX  -O3 -Wall -DNDEBUG    -I. -I/usr/local/include/SDL -I/usr/local/include/  -c /usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client/main.c -o ../../build/FreeBSD.i386/Release/client/main.o
g++ -L/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/ -L/usr/local/lib  -o "../../dist/FreeBSD.i386/Release/stargella" ../../build/FreeBSD.i386/Release/client/main.o   -s /usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libcommon.a /usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libconsole.a /usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a /usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libsys.a /usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libzpkg.a  -lGL -lGLU -lGLEW -lSDL -lSDLmain 
/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a(input.o)(.text+0xd8): In function `InputTick':
: undefined reference to `Console'
/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a(input.o)(.text+0x145): In function `InputTick':
: undefined reference to `Console'
/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a(input.o)(.text+0x155): In function `InputTick':
: undefined reference to `Console'
/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a(input.o)(.text+0x191): In function `InputTick':
: undefined reference to `Console'
/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a(input.o)(.text+0x1a1): In function `InputTick':
: undefined reference to `Console'
/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a(input.o)(.text+0x1ab): In function `InputTick':
: undefined reference to `ConsoleHandleInput'
/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a(input.o)(.text+0x249): In function `InputInit':
: undefined reference to `ConsoleInit'
/usr/home/Terry/Projects/Games/cbp-tree/Stargella/src/client//../../build/FreeBSD.i386/Release/libinput.a(input.o)(.text+0x36d): In function `InputInit':
: undefined reference to `ConsoleToggle'

At the source level, the input module interacts with the console module through function calls `ConsoleWhatWhat()` and `extern Console_t Console;` from input.c; the actual details live in the console module. The reason for the global variable, is to expose some oft' needed data as members rather then making repeated function calls to query it. While the concept of multiple consoles is kept in mind, it is still effectively a singleton object.

What I don't understand is why it pops a cork over inputs references to console. A static library is basically a bundle of object files, so I would think it is fair to expect the linker to understand not everything will be in the object files until all is said and done... hell, how would a static library use data from a shared library otherwise? No errors are being generated from the other modules, although for example, the common module is used in practically every other module (hence the name), but no errors are being spit out about that. I would also think */*.o -> x.a; *.o x.a -> foo to be equivalent enough to */*.o, *.o -> foo for all intents and purposes....

Before experimentation with using an IDE to handle the builds more portably, every thing was built using a build.sh / build.bat script that generated object files for each source file, then linked into the corresponding executable and shared library files. That worked perfectly until I tried to get Microsoft's compiler to combine build/os.arch/module_source.obj into build/os.arch/foo.exe 8=).

The 'wrapper' is also made up of it's main.obj, libcommon.a, and libsys.a, where the sys module relies on functions in the common module.

Any ideas or am I just missing something?
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.

Last edited by TerryP; 18th January 2010 at 09:33 PM. Reason: typo fix in topic name
Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
snd_emu10k1 and static kly FreeBSD General 3 17th September 2009 01:28 PM
Shared object not found 'libwrap.so.4' magic FreeBSD General 3 22nd July 2009 09:36 PM
shared libraries and linux emulation Business_woman FreeBSD General 4 16th November 2008 10:03 AM
Why does cvsup need x11 libs? thevirtuesofxen FreeBSD General 6 17th August 2008 09:30 AM
Update from 6.3 to 7.0 (libs missing etc.) Calderon FreeBSD Installation and Upgrading 16 17th May 2008 09:03 PM

All times are GMT. The time now is 08:29 AM.

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick