Re: Registries

David Abrahams wrote:
> Maybe this will make it easier:

Sigh.

Expanded source code is here for everybody to look at:

  http://cci.lbl.gov/~rwgk/shortcuts/sandbx/dll_experiment/

David, you can also get this with cvs update in rwgk/sandbox.

There are two alternatives:
  1. not using -tlocal
  2. using -tlocal

Here are the results (in that order):

% ./build.py 
rm -rf a.o a.so b.o b.so cxx_repository so_locations
cxx -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -DNDEBUG -O2 -I/usr/local_cci/Python-2.2.1t/include/python2.2 -c a.cpp
cxx -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -DNDEBUG -O2 -I/usr/local_cci/Python-2.2.1t/include/python2.2 -c b.cpp
cxx -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*' -o a.so a.o -lm
cxx -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*' -o b.so b.o -lm
redbelly:/net/cci/rwgk/dist/sandbx/dll_experiment % ./tst_a_b.py 
0
1
2
3
module a
module b
cpp a
cpp b
hello a
hello b

% ./build.py -tlocal
rm -rf a.o a.so b.o b.so cxx_repository so_locations
cxx -std strict_ansi -tlocal -msg_display_number -msg_disable 186,450,1115 -DNDEBUG -O2 -I/usr/local_cci/Python-2.2.1t/include/python2.2 -c a.cpp
cxx -std strict_ansi -tlocal -msg_display_number -msg_disable 186,450,1115 -DNDEBUG -O2 -I/usr/local_cci/Python-2.2.1t/include/python2.2 -c b.cpp
cxx -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*' -o a.so a.o -lm
cxx -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*' -o b.so b.o -lm
redbelly:/net/cci/rwgk/dist/sandbx/dll_experiment % ./tst_a_b.py
0
0
1
1
module a
module b
cpp a
cpp b
hello a
hello b


If you look at the source code you will see that I made an attempt to
reproduce the problems I had while working on the Boost.Python V1
cross-module support (see my message from yesterday). In this respect I
was (fortunately!) not successful. But the situation was different: the
template instantiations came from the same static library which I used
to build like this:

  ar r libboost_python.a class.o module.o ... cxx_repository/*

Maybe my problems were the result of bad interactions with the
cxx_repository, and maybe everything is fine if we use -tlocal
(which we prefer anyway for other reasons). But then again,
why did cross-module inheritance work (non-virtual only) ...?
I guess I am still confused.

Ralf


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Boost-langbinding mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
From nobody Sat Jul 19 11:06:27 2003
Return-Path: <[email protected]>
Received: from smtp01.mrf.mail.rcn.net ([207.172.4.60] verified)
  by stlport.com (CommuniGate Pro SMTP 3.5.9)
  with ESMTP id 285922 for [email protected]; Fri, 18 Jul 2003 12:22:29 -0700
Received: from 146-115-123-42.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com ([146.115.123.42] helo=PENGUIN.boost-consulting.com)
	by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 19daoL-0002SJ-00; Fri, 18 Jul 2003 15:22:33 -0400
To: [email protected]
Cc: [email protected]
Subject: Re: [Boost-langbinding] Registries
References: <[email protected]>
From: David Abrahams <[email protected]>
Date: Fri, 18 Jul 2003 15:22:13 -0400
In-Reply-To: <[email protected]> (Ralf W.
 Grosse-Kunstleve's message of "Fri, 18 Jul 2003 12:09:17 -0700 (PDT)")
Message-ID: <[email protected]>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 46
Xref: PENGUIN langbinding-mbox:115
X-Gnus-Newsgroup: langbinding-mbox:115   Sat Jul 19 11:06:27 2003

"Ralf W. Grosse-Kunstleve" <[email protected]> writes:

>> Maybe this will make it easier:
>
> Sigh.
>
> Expanded source code is here for everybody to look at:
>
>   http://cci.lbl.gov/~rwgk/shortcuts/sandbx/dll_experiment/
>
> David, you can also get this with cvs update in rwgk/sandbox.
>
> There are two alternatives:
>   1. not using -tlocal
>   2. using -tlocal

Thanks for doing this

<snip>

> If you look at the source code you will see that I made an attempt
> to reproduce the problems I had while working on the Boost.Python V1
> cross-module support (see my message from yesterday). In this
> respect I was (fortunately!) not successful. But the situation was
> different: the template instantiations came from the same static
> library which I used to build like this:
>
>   ar r libboost_python.a class.o module.o ... cxx_repository/*
>
> Maybe my problems were the result of bad interactions with the
> cxx_repository, and maybe everything is fine if we use -tlocal
> (which we prefer anyway for other reasons). But then again,
> why did cross-module inheritance work (non-virtual only) ...?

I don't know; were we inadvertently building a shared lib for Tru64?

> I guess I am still confused.

Me too:  all the evidence points to Tru64 behaving perfectly well
right now.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com