Zaineb Suleman <[EMAIL PROTECTED]> writes:
Ptolemy doesn't support incremental linking for the NT Platform as
yet. Does anybody knows how can this feature be added . Does it
mean some changes in the makefile, for the link options or is
there something more to it.
I'll be obliged if somebody can guide me on implementing
incremental linking in Ptolemy for NT.
------
http://ptolemy.eecs.berkeley.edu/~cxh/ptpub/nt/ptntbugs.html
basically describes the problem with Ptolemy Classic under NT:
--start--
Incremental linking still fails
Error: Error in creating shared object, command failed: g++
-shared -o /tmp/__ptlink1032_2.so /usr/cxh/src/pt/SDFMyRamp.o
In brief, the problem is that incremental linking of user stars
is broken in the NT port. In the past, I've tried to build a
shared library version of Ptolemy under NT, but had various
problems with the constructors etc.
The alternative to building a shared library version is to build
a static version of pigiRpc, which is what is currently built under
NT. The problem with a static pigiRpc is that incremental
linking is tricky. We had it working under SunOS years ago with
the BSD ld -a flag, but it looks like that is not supported
The binutils2-9.1/ld/TODO file says:
Support the "traditional" BSD -A flag (incremental loading).
(There is a -A flag in ld now, but it is used to specify the
architecture. That should probably be changed.)
One workaround would be to avoid incrementally linking your stars
and instead build a pigiRpc that had the stars built in. The way to do
this is to create a makefile for your stars, build a library and
then modify
$PTOLEMY/mk/stars.mk so that your stars are built in. The programmer's
manual has some info about this, see also $PTOLEMY/src/pigiExample
--end--
The first issue is that we would need to build a shared library
version of pigi. This can be done by modifying $PTOLEMY/mk/config-nt4.mk
I believe that the problem is that Windows dlls have issues with
global static variables or constructors. I'm not sure about the
details, I have not looked at this for over a year. The problem
is that SDFDomain.cc has lines like:
// declare a prototype
static SDFDomain proto;
// declare a prototype default target object.
static SDFTarget defaultSDFtarget("default-SDF",
"Runs SDF systems on the local workstation using either the default\n"
"one-processor SDF scheduler or Joe's clustering loop scheduler.");
static KnownTarget entryDefault(defaultSDFtarget,"default-SDF");
static SDFPTclTarget SDFPTclTargetProto("SDF-to-PTcl",
"Generate CG PTcl Equivalent");
static KnownTarget entryPTcl(SDFPTclTargetProto,"SDF-to-PTcl");
Working around this problem would require restructuring how the
Domains are created. Rather than static objects, we would have to
have some sort of method create these objects for us. This is a
fairly complex issue to handle. I'm not that up on Windows dlls, so
someone might have a better idea.
Another approach would be to try to use Microsoft Visual C++ to build
a shared library ptcl and work with that as a test case and then
transfer what ever is learned over to Cygwin. I think that getting
shared libraries to work under Cygwin might be a little more of a
black art, and it might be easier to use MSVC++ first.
To be honest though, the quickest thing would be to install Linux,
where Ptolemy Classic runs faster than under NT, and there is better
support.
I have no plans to work further on the Ptolemy Classic NT port anytime
soon. If there was a new release of Cygwin, I might give it a try
just for laughs to see if the speed/signal problems went away.
-Christopher
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]