I think this is because of the ordering on the command line.  If I
recall correctly, when two libraries depend on each other, the
providing library needs to be listed *after* the consuming library.
So you should put gzstream after m5.

This is because with static libs linked with -l, the linker only takes
unresolved symbols that it knows about from the library.  If you were
to link in the library as an object, i.e. full path with .a like
you're linking libmemory.a, then this doesn't happen.

  Nate

On Fri, Aug 7, 2009 at 12:20 PM, Derek Hower<derek.ho...@gmail.com> wrote:
> Command:
>
> g++ -o bochs -I/u/d/r/drh5/mfacet/rocks
> -I/u/d/r/drh5/mfacet/rocks/bochs
> -I/u/d/r/drh5/mfacet/rocks/gem5/src/mem/ruby -DBX_WITH_RUBY=1
> -DBX_241=1 -g -pg -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
> -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
> -DBX_SHARE_PATH=\"/usr/local/share/bochs\" logio.o main.o config.o
> load32bitOShack.o pc_system.o osdep.o plugin.o crc.o
> -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Wl,--export-dynamic
> -L/u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory/../gzstream
> -L/u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory
> iodev/libiodev.a cpu/libcpu.a memory/libmemory.a gui/libgui.a
> disasm/libdisasm.a ../bx_ruby_interface/libinstrument.a fpu/libfpu.a
> -L/usr/lib64 -lSM -lICE -lX11 -lXpm -lSDL -lncurses -lgzstream
> -lm5_prof -lpthread -lreadline -ltermcap -lm
>
> Errors:
>
> /u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory/libm5_prof.a(Tracer.po):
> In function `Tracer::stopTrace()':
> /afs/cs.wisc.edu/p/multifacet/users/drh5/gem5/build/LIBRUBY_MOESI_CMP_directory/mem/ruby/recorder/Tracer.cc:95:
> undefined reference to `gzstreambase::close()'
> /u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory/libm5_prof.a(Tracer.po):
> In function `ogzstream::open(char const*, int)':
> /afs/cs.wisc.edu/p/multifacet/users/drh5/gem5/build/gzstream/gzstream.hh:111:
> undefined reference to `gzstreambase::open(char const*, int)'
> /u/d/r/drh5/mfacet/rocks/gem5/build/LIBRUBY_MOESI_CMP_directory/libm5_prof.a(Tracer.po):
> In function `Tracer::stopTrace()':
>
> ...etc, etc
>
> -Derek
>
> On Fri, Aug 7, 2009 at 2:10 PM, nathan binkert<n...@binkert.org> wrote:
>>>>> How can I make it compile gzstream?
>>>> There should be a libgzstream.a in build/gzstream/libgzstream.a.
>>>> You'll have to specify that in your final link stage along with
>>>> -lm5_foo
>>>
>>> Yes, there should, but theres not.  If you build the dynamic library
>>> libgzstream.a gets built, but when you build the static library this
>>> is the contents of build/gzstream:
>>>
>>>
>>> ale-01:rocks (64)% ls gem5/build/gzstream/
>>> gzstream.cc@  gzstream.hh@  SConscript@
>>>
>>> I also built the dynamic m5 library so that libgztream.a would be
>>> created, but linking against it doesn't fix the problem.
>> what is the error message you get and what is your linker command line?
>>
>>  Nate
>> _______________________________________________
>> m5-dev mailing list
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to