Using udk 8, freestore (fs) and STL

[J. L. Schilling]

I'm using UW 7.1.1.
Is thier another workaround.

[Sorry for the post but your above mail isn't working (quota exceeded).]

We have made a quick patch to the "fs" tool to allow it
to get past the error you were getting on the <memory> header.

Do anonymous ftp to ftpput.sco.com, go to the tmp/fs-patch/
directory, download the fsipp executable, and move it into
/usr/ccs/lib/ (saving the old one that was there).

Let us know if you have other problems past this first one.

As stated originally, the best approach is to upgrade to UW 7.1.3
(for your development platform, doesn't have to be for all your
deployment platforms), and then use "memtool".

Jonathan Schilling

Has anyone tried using freestore (fs) on UnixWare?
It's a tool which helps find memory leaks. It's part of UDK
One should first instrument the code (at compilation phase) with the
compiler flag "-f"
At this phase, only test/toy source file pass.

fs will work for a lot of C++ sources, but once you get into
the STL headers, it tends to fall down.
If you are on UnixWare 7.1.3, try using the new "memtool" memory
checking tool. This is more general and robust than "fs", and
will flag various kinds of memory errors. See
http://uw713doc.sco.com/en/man/html.1/memtool.1.html
for the full details.
Jonathan Schilling

[Alon Blayer-Gat]

Hi,

Thank you,

It works fine with STL in a test code.

But, I'm also using the ACE library, so added a Reactor instance to my test
code (A dispatch mechanism):

In compilation with -f I get the following warnings:

"/usr/include/netinet/in.h", line 339: warning: declaration of a member with
the same name as its class

char ip_opts[40];

^

"/usr/include/sys/sockio.h", line 94: warning: linkage specification is
incompatible with previous "ioctl" (declared at line 261 of
"/usr/include/unistd.h")

static int ioctl(int __a1, int __a2, ...)

In linkage with -lfs -l++, I get the following errors:

Undefined first referenced

symbol in file

ACE_Select_Reactor_T<T1>::~ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<A
CE_Token>>(void) [with T1=ACE_Select_Reactor_Token_T<ACE_Token>] test.o

UX:ld: ERROR: Symbol referencing errors. No output written to
/mvobs//SMSC/genie/bin/x86at.UDK.8/test

Any ideas ?

Best Regards,

Alon Blayer-Gat

Post by J. L. Schilling

I'm using UW 7.1.1.
Is thier another workaround.

[Sorry for the post but your above mail isn't working (quota exceeded).]
We have made a quick patch to the "fs" tool to allow it
to get past the error you were getting on the <memory> header.
Do anonymous ftp to ftpput.sco.com, go to the tmp/fs-patch/
directory, download the fsipp executable, and move it into
/usr/ccs/lib/ (saving the old one that was there).
Let us know if you have other problems past this first one.
As stated originally, the best approach is to upgrade to UW 7.1.3
(for your development platform, doesn't have to be for all your
deployment platforms), and then use "memtool".
Jonathan Schilling

Has anyone tried using freestore (fs) on UnixWare?
It's a tool which helps find memory leaks. It's part of UDK
One should first instrument the code (at compilation phase) with the
compiler flag "-f"
At this phase, only test/toy source file pass.

fs will work for a lot of C++ sources, but once you get into
the STL headers, it tends to fall down.
If you are on UnixWare 7.1.3, try using the new "memtool" memory
checking tool. This is more general and robust than "fs", and
will flag various kinds of memory errors. See
http://uw713doc.sco.com/en/man/html.1/memtool.1.html
for the full details.
Jonathan Schilling

[J. L. Schilling]

Post by Alon Blayer-Gat
[...]
But, I'm also using the ACE library, so added a Reactor instance to my test
"/usr/include/netinet/in.h", line 339: warning: declaration of a member with
the same name as its class
char ip_opts[40];

Some of the UnixWare networking headers have usages that the C++ compiler
warns about, although they cause no harm. Normally these warnings are
suppressed, since there's nothing a user can do about system headers.

However, when compiling with -f, the source code is preprocessed and
instrumented, and the offending usages now look like they occur in
user code, not system headers. Hence the warnings appear. You can
ignore them.

Post by Alon Blayer-Gat
"/usr/include/sys/sockio.h", line 94: warning: linkage specification is
incompatible with previous "ioctl" (declared at line 261 of
"/usr/include/unistd.h")
static int ioctl(int __a1, int __a2, ...)

Same as above.

Post by Alon Blayer-Gat
Undefined first referenced
symbol in file
ACE_Select_Reactor_T<T1>::~ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<A
CE_Token>>(void) [with T1=ACE_Select_Reactor_Token_T<ACE_Token>] test.o
UX:ld: ERROR: Symbol referencing errors. No output written to
/mvobs//SMSC/genie/bin/x86at.UDK.8/test

This looks like a template instantiation issue unrelated to using "fs".
(If you don't compile or link with "fs", do you still get this?)

What CC template instantiation options are you using? Are you creating
an archive, in which case you need to use CC -Tprelink_objects? Are you
using the default auto instantiation mechanism? Showing your whole
link command line might help.

Jonathan Schilling

[Alon Blayer-Gat]

Hi,

1. I'm linking an executable, not a library.
2. If I remove the '-f' from the linkage phase, linkage error does not
reproduce.
Never the less every object (but main() (test.cc) itself is insrumented
with -f)
If this points out that I'll be able to detect leaks in every source file
but my main(),
I can live with it.

3. My link command:
CC -DCOMP_SDK -DUNW -DARCH_X86AT_UDK_8 -DXBYTE_ORDER -DTEMPLATE_INLINE= -Tlo
cal -Kpentium_pro -DTEMPLATE_DECL=template\<\> -Wf,--diag_suppress -Wf,9 -I/
mvobs/general/code/inc/x86at.UDK.8 -I. -I../inc -I/mvobs//SMSC/genie/.export
_inc -I/mvobs/ACE/x86at.UDK.8/.export_inc -I/mvobs/INFRA/.export_inc -I/
mvobs/SMSC/api/.export_inc -I/mvobs/SMSC/ei/main/.export_inc -I/mvobs/SMSC
/shared/.export_inc -I/mvobs/freeware/.export_inc -I/mvobs/general/.export
_inc -I/mvobs/RW/src -g -DDBG_LIB=\"genie\" -DNYHASH_DEBUG -o
/mvobs//SMSC/genie/bin/x86at.UDK.8/test test.cc
/mvobs//SMSC/genie/lib/x86at.UDK.8/genie.a
/mvobs/SMSC/ei/main/lib/x86at.UDK.8/ei-main.a
/mvobs/SMSC/api/lib/x86at.UDK.8/api.a /mvobs/INFRA/lib/x86at.UDK.8/tools.a
/mvobs/INFRA/lib/x86at.UDK.8/comm.a /mvobs/INFRA/lib/x86at.UDK.8/events.a
/mvobs/INFRA/lib/x86at.UDK.8/adt.a /mvobs/INFRA/lib/x86at.UDK.8/debug.a
/mvobs/INFRA/lib/x86at.UDK.8/comp.a
/mvobs/ACE/x86at.UDK.8/lib/x86at.UDK.8/ace.a
/mvobs/ACE/x86at.UDK.8/lib/x86at.UDK.8/ace_ssl.a
/mvobs/freeware/lib/x86at.UDK.8/ssl.a
/mvobs/freeware/lib/x86at.UDK.8/crypto.a -lsocket -lnsl -lm -lcrypt -ldl -lg
en -Kthread -L/usr/local/oracle/v8.1.7/lib -lclntsh -lwtc8 -R/usr/local/orac
le/v8.1.7/lib -lx25 -lfs -l++


Best Regards,
Alon Blayer-Gat

[Alon Blayer-Gat]

With my real main() it still does not work although i removed the -f flag

Here is my link command:
CC -DCOMP_SDK -DUNW -DARCH_X86AT_UDK_8 -DXBYTE_ORDER -DTEMPLATE_INLINE= -Tlo
cal -Kpentium_pro -DTEMPLATE_DECL=template\<\> -Wf,--diag_suppress -Wf,9 -I/
mvobs/general/code/inc/x86at.UDK.8 -I. -I../inc -I/mvobs//SMSC/genie/.export
_inc -I/mvobs/ACE/x86at.UDK.8/.export_inc -I/mvobs/INFRA/.export_inc -I/
mvobs/SMSC/api/.export_inc -I/mvobs/SMSC/ei/main/.export_inc -I/mvobs/SMSC
/shared/.export_inc -I/mvobs/freeware/.export_inc -I/mvobs/general/.export
_inc -I/mvobs/RW/src -g -DDBG_LIB=\"genie\" -o
/mvobs//SMSC/genie/bin/x86at.UDK.8/genie_ei genie_ei.cc
/mvobs//SMSC/genie/lib/x86at.UDK.8/genie.a
/mvobs/SMSC/ei/main/lib/x86at.UDK.8/ei-main.a
/mvobs/SMSC/api/lib/x86at.UDK.8/api.a /mvobs/INFRA/lib/x86at.UDK.8/tools.a
/mvobs/INFRA/lib/x86at.UDK.8/comm.a /mvobs/INFRA/lib/x86at.UDK.8/events.a
/mvobs/INFRA/lib/x86at.UDK.8/adt.a /mvobs/INFRA/lib/x86at.UDK.8/debug.a
/mvobs/INFRA/lib/x86at.UDK.8/comp.a
/mvobs/ACE/x86at.UDK.8/lib/x86at.UDK.8/ace.a
/mvobs/ACE/x86at.UDK.8/lib/x86at.UDK.8/ace_ssl.a
/mvobs/freeware/lib/x86at.UDK.8/ssl.a
/mvobs/freeware/lib/x86at.UDK.8/crypto.a -lsocket -lnsl -lm -lcrypt -ldl -lg
en -Kthread -L/usr/local/oracle/v8.1.7/lib -lclntsh -lwtc8 -R/usr/local/orac
le/v8.1.7/lib -lx25 -lfs -l++

Regards,
Alon

[Alon Blayer-Gat]

Post by J. L. Schilling
This looks like a template instantiation issue unrelated to using "fs".
(If you don't compile or link with "fs", do you still get this?)

Yes, without the -lfs -l++ it links fine

[Alon Blayer-Gat]

I'm using -Tlocal in both compilation and later on in linkage.
I have changed it to -Tused.
Errors are gone but I'm not sure that program will work as it should.

Alon

[J. L. Schilling]

Post by Alon Blayer-Gat
I'm using -Tlocal in both compilation and later on in linkage.
I have changed it to -Tused.
Errors are gone but I'm not sure that program will work as it should.

From other posts, your application is a bunch of .a archives pulled in
by one .cc main program.

The best approach is to compile all the source files that go into
the .a's with -Tauto (the default), and not either -Tlocal or -Tused.

Then do a CC -Tprelink_objects on all the .o's that are going into a
particular archive, before doing the "ar" command to create the archive.

Then compile the main program with the default -Tauto as well.
Then link.

If you take this approach, does it link correctly, with and without
using "fs"?

Jonathan Schilling