In terms of specific steps to avoid problems, it's been too long ago
since I wrote those GIL management patches for TnFOX for me to be
able to comment usefully. Getting the sequences correct took a lot of
trial and error at the time. All I can say is if you're seeing weird
hangs under load, the
> I feel a bit out of my depths here now wrt to all that boost magic
> but I've definitely learned a bunch :)
Much of the "boost magic" we talked about is now plain C++11.
It's very worth while to read "The C++ standard library" by Josuttis
from cover to cover (it's about 1000 pages, get the C++
On 17 Apr 2013 at 17:13, Holger Joukl wrote:
> // the global per-thread exception storage
> boost::unordered_map exception_map;
You can't assume pthread_t is of integral type. You can a thread_t
(from C11) I believe. You may not care on your supported platforms
though.
> throw std::runtime
On 10 Apr 2013 at 13:48, Holger Joukl wrote:
> > If you don't have C++11 in your C++, Boost provides an okay partial
> > implementation of C++11 exception support.
>
> I'll look into this. This would then mean instrumenting some object with a
> place
> to store the caught exception to re-raise up
On 8 Apr 2013 at 14:11, Holger Joukl wrote:
> > I have found a couple of references.
> > http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html (see static-libgcc)
> > http://gcc.gnu.org/wiki/Visibility
>
> Thanks, I'll need to look into these.
I wrote the second one. Really not sure how that helps
On 22 Mar 2013 at 14:33, Alex Leach wrote:
> So, in Environment's destructor, which I thought was a no-op, FastMutex's
> destructor is also being called. Now, that's a bit of a bummer. As far as
> I can tell (I'm still very new to C++; coming from Python), unlike how I
> hacked the initialis
On 20 Mar 2013 at 18:43, Alex Leach wrote:
> Thanks for that link. I checked out the tnfox library, which the FAQ
> refers to as having a thread-safe implementation of invoke.hpp. tnfox,
> whatever it is, also has an extensive indexing_suite, complete with a
> template for std::list containe
On 26 Dec 2012 at 11:49, Adam Preble wrote:
> Also if you're curious, I tried that above experiment with .NET code using
> IronPython and Python.NET. IronPython took it in stride, and Python.NET
> died at #3; it couldn't create a Python implementation of a .NET interface
> because it would choke
e data by std :: string.When the python
> interface,it store the data by the Python str object. And perhaps this is
> a good way.
>
>
> 2012/12/25 Niall Douglas
>
> > Traditionally, the proper solution to avoid deep copies is to wrap a
> > std::shared_ptr inst
On 25 Dec 2012 at 12:14, John Zwinck wrote:
> The code I published is agnostic about iterators and iteration--the user
> must explicitly decide when the GIL is to be released and reacquired.
> I'm sure there could be fancier ways of doing it, e.g. with tags given
> to BPL's class_::def() for lo
Traditionally, the proper solution to avoid deep copies is to wrap a
std::shared_ptr instead of a std::string directly.
If your strings are short of course, it may well be faster to leave
it as is. std::shared_ptr is not lightweight and may use atomic
instructions, the bandwidth for which in a
In your C++ you simply need to ensure that Python gets a regular
chance to execute in any native loop you execute so it can do its
housekeeping. One way is PyErr_CheckSignals(), but that won't do for
long running loops, only short ones, because it doesn't do much
housekeeping.
In my own code I
On 16 Dec 2012 at 20:37, John Zwinck wrote:
> There are many questions and example classes online for dealing with
> Python's Global Interpreter Lock (GIL) using RAII. I think Boost.Python
> should provide this functionality, rather than having users who build
> hybrid C++/Python applications
There should be no reason you can't wrap bound Boost/C++11 Functor
instances and pass them in as callables to Python. You might need a
little machinery to let BPL know what the function prototype is
(assuming BPL doesn't already understand
boost::function/std::function), but it ought to be stra
Could use Cython. You're still going to have to use DLLs though. With
Python it's very hard to avoid DLLs.
Niall
On 13 Aug 2012 at 16:05, Murat Atalay wrote:
> Hello Everyone,
>
> Currently, I am trying to call C++ classes and functions from python inside
> my C++ program. I want to be able t
On windows, the only near equivalent to valgrind is Intel's suite of
very expensive tools. If your company already has a licence, they are
very good. If not, fire up a copy of Linux on your nearest VM node
and port a small example of the problem in your BPL app over to GCC.
Niall
On 21 Jul 20
Use a much older boost, one compatible with an ancient compiler like
gcc 3.3.5.
Or use a newer gcc.
Niall
On 19 Jul 2012 at 9:40, Harkirat Singh wrote:
> While compiling boost.python particularly, i get this error. Is there any
> workaround on this.
>
>
> *
> In file included from boost/unor
t; Thanks a lot for your time.
>
> I checked all the DLL's. Everything is showing ok. Only one is, IEFrame.DLL
> and in that for one function it is showing red in color. Function name as
> "#270".
>
> We are not using that function/DLL anways.
>
> Regards,
>
> The same code works, if I use LoadLibrary in C++. But when I try to build
> the C++ DLL code with extention ".pyd", it is throwing error.
>
> FYI, the C++ Class names are mangled.
>
> Regards,
> Raju.
>
> On Thu, Jun 21, 2012 at 2:30 PM, Niall Douglas
You might find Microsoft's Dependency Walker useful.
http://www.dependencywalker.com/
Niall
On 21 Jun 2012 at 10:01, Nagaraju wrote:
> Hi All,
>
> I have written a C++ DLL. That DLL depends on some other libraries. I have
> kept all those dependent libraries in the release folder.
>
> Now in
On 14 Jun 2012 at 15:01, Wichert Akkerman wrote:
> On 06/14/2012 02:33 PM, Niall Douglas wrote:
> > Do you think that this answer is worth adding to the BPL FAQ?
> > Normally you don't need to derive from Python's Exception object, and
> > indeed in my own custom ex
Do you think that this answer is worth adding to the BPL FAQ?
Normally you don't need to derive from Python's Exception object, and
indeed in my own custom exception implementations I never did so.
However, if this has changed, an FAQ entry is appropriate.
Ideally, a wishlist work item would ma
On 27 May 2012 at 20:37, Suresh Joshi wrote:
> (2) From Python, I would like to manipulate the memory of a buffer stored
> within Foo. In my REAL code, the only accessor I can use is Address() which
> returns a void pointer, which Py++/BP flips into an opaque pointer (which I
> don't think I can u
You're passing a null object pointer, so BPL correctly fails an
assertion check?
Niall
On 28 May 2012 at 21:39, Adam Preble wrote:
> I wanted to provide an instance of a particular object I'm using for
> Stackless Python state management. I'm trying to take over the green
> thread management s
On 27 May 2012 at 10:26, Adam Preble wrote:
> I don't know if I can build on Linux but I have see ways to play with the
> clock and setting affinity. However, I don't know how to take the GIL
> properly during destruction. What we're talking about is a shared_ptr to
> an interface that was creat
Try pinning everything to a single CPU, see what happens.
Try pinning the CPU clock speed to its minimum. If it doesn't trip,
you have a timing race.
If you can build on Linux, try valgrind.
Oh, you mentioned bits you weren't locking when destroying. I'd lock
those and see what happens.
Niall
On 22 May 2012 at 18:33, Jonas Wielicki wrote:
> > BTW - can I just clarify you ARE compiling the entire of BPL using
> > C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but
> > not the other way round), but I can see nests of vipers in it.
> Ehm, I guess not, so I just downloade
On 21 May 2012 at 18:43, Jonas Wielicki wrote:
> On 21.05.2012 17:55, Niall Douglas wrote:
> > 1. Does the bug occur in non-optimised as well as optimised builds?
> It does.
Joy.
> > 2. Does the bug occur when C++11 is turned off?
> It does not.
Not so much joy. It could,
On 19 May 2012 at 12:01, Jonas Wielicki wrote:
> I am working on a bugreport for the gcc folks right now, and during that
> I came across the release notes for gcc 4.7[1] and found the following.
That's a huge amount of new compliance with C++11. No wonder there
are bugs.
> However, it seems th
just so we can link to the bug from here.
Niall
On 18 May 2012 at 20:28, Jonas Wielicki wrote:
> On 18.05.2012 19:47, Niall Douglas wrote:
> > So it was a bug in GCC after all. Useful to know.
> Sorry that I forgot to mention. I was pretty sure it was the GCC after I
> tried wit
So it was a bug in GCC after all. Useful to know.
Niall
On 18 May 2012 at 10:41, Jonas Wielicki wrote:
> On 17/05/12 23:42, Gabe Rives-Corbett wrote:
> > I'm getting a seg fault when trying to call a virtual method on a base
> > class from python.
> I had a similar problem a few days ago. Whic
On 14 May 2012 at 16:22, Jonas Wielicki wrote:
> > Debian doesn't necessarily install by default
> > multiple versions of compilers, rather they're in the repos available
> > as package dependencies. Surely Fedora is the same?
> Nope, I was talking about the repositories.
Well, well. Didn't thi
On 14 May 2012 at 15:11, Jonas Wielicki wrote:
> On 05/14/2012 01:33 PM, Niall Douglas wrote:
> > Most distros bundle multiple versions of gcc due to this exact
> > problem with frequent bugs. Debian, at least, usually has the
> > previous version and for many years also ha
On 14 May 2012 at 12:53, Jonas Wielicki wrote:
> > Generally speaking GCC bugs fix themselves over
> > time, so you can revert temporarily to an older GCC. Bugs in GCC are
> > common enough that if my code fails, I first think it's GCC's fault
> > :)
> Hm. GCC updates are rather rare though I th
On 14 May 2012 at 9:48, Jonas Wielicki wrote:
> I recently upgraded to boost::python 1.48 and g++ 4.7 (fedora 17). This
> broke a project of mine as it crashes when passing an object with
> virtual inheritance from python back to C++ (e.g. during a method call).
> A minimal test case is attached.
On 13 May 2012 at 14:31, Stefan Seefeld wrote:
> On 05/13/2012 05:18 AM, Michele De Stefano wrote:
> > I've read a recent post by Jim Bosch saying that the original
> > developers of Boost Python are not going to upgrade it for supporting
> > C++11 standard libraries.
>
> Can you elaborate a litt
On 13 May 2012 at 21:28, Michele De Stefano wrote:
> I read that post from Jim Bosch and I thought he knew something more about
> Boost Python development.
What Jim didn't mention is how BPL v2 (the current version) was first
written. Basically, Berkeley paid Dave Abrahams a chunk of money to
(
On 12 May 2012 at 18:48, Jim Bosch wrote:
> Another thing to consider is C++11 support, and particularly support for
> the C++11 standard library. I don't know think any of the original
> library builders or maintainers has any plans to devote any of their own
> time to add support for e.g. st
On 8 May 2012 at 1:14, Matthew Scouten wrote:
> Hello,
> I have recently been laid off from a job where a made a lot of good
> use of Boost.Python. I would like to give something back (while incidentally
> keeping my skills from getting rusty). I have already been following the
> boost-pytho
On 7 May 2012 at 10:30, Adam Preble wrote:
> I want to make sure I understand the repercussions.
>
> I understand if I were introducing C++ objects into the Python runtime as
> internal references that I would be inviting disaster if I delete them on
> the C++ side, but continue to use them on th
Only Python may delete a python managed object. You cannot destroy
any python object explicitly from the C++ side of things.
Solution: allow the python wrapper and C++ instance being wrapped to
detach from one another. That way if the C++ object is deleted, you
zombify the python representation
matter) and thought Python was
> not typed. If not, how can one convert Python integers to void*? Googled
> but didn't find an answer.
>
> Regards,
> Ehsan
>
>
> On Tue, May 1, 2012 at 9:18 AM, Niall Douglas
> wrote:
>
> > A HWND is always a void * i.e. an
A HWND is always a void * i.e. an opaque pointer. Unfortunately some
people using BPL think that BPL can't handle opaque pointers, so they
do fun stuff like use a thunk struct type for void * instead, and
wrap the lot in manual pointer casting. It's far easier just to
declare it an opaque point
On 19 Apr 2012 at 16:30, JS Unkn0wn wrote:
> Yes, my current problem is embedding on Windows, but my requirements
> are the same as compiling to the embedded system, as the primary
> target is with the Arm processor + proprietary OS. The Windows
> compilation is just a temporary set up until my ki
So, to be clear, your problem has absolutely nothing to do with any
embedded system. Your sole problem is that you can't get embedding to
work on Windows?
Niall
On 19 Apr 2012 at 15:57, JS Unkn0wn wrote:
> On Thu, Apr 19, 2012 at 3:41 PM, Niall Douglas
> wrote:
> >
> &g
On 19 Apr 2012 at 14:40, JS Unkn0wn wrote:
> What I'm trying to figure out now are fixing the errors explained on my
> blog entry ( http://goo.gl/K9G36 ).
I think you will struggle to get much help here by posting links to
other places. No one here has time to read blogs. You need to
formulate
Surely Python absolutely requires DLL support for its extension
support?
Anything targeted at the Windows API will assume DLL support. You
might fare better using a GCC ecosystem. Your proprietary device, I
would assume, will use a GCC ecosystem anyway.
Niall
On 19 Apr 2012 at 0:09, JS Unkn0
On 6 Apr 2012 at 20:33, Payam Shiva wrote:
> Thank you Adam. I tried what you said, but it doesn't work for me. It
> gave an error, among a bunch of others, that it couldn't find
> python26.lib. I have Python 2.7 installed on my computer, so it makes
> sense. Maybe the person who compiled the libr
On 29 Mar 2012 at 16:14, Kyle Cronan wrote:
> So my question is, why isn't taking the address of some instance of a
> templatized function and passing it to def() enough to require the
> function definition to exist? Should this be considered a usability
> bug in the library, a problem with my co
On 18 Mar 2012 at 11:54, Jim Bosch wrote:
> We didn't go into a lot of depth on the threading, I'm afraid, as one of
> the problems is that the guy starting the effort - me - doesn't actually
> know much about threaded programming. But I am hoping that I can design
> things in such a way that
On 18 Mar 2012 at 12:05, Stefan Seefeld wrote:
> > We didn't go into a lot of depth on the threading, I'm afraid, as one
> > of the problems is that the guy starting the effort - me - doesn't
> > actually know much about threaded programming. But I am hoping that I
> > can design things in such a
On 17 Mar 2012 at 22:20, Adam Preble wrote:
> > If by "Python side" you mean Boost.Python, then I agree: BPL has no
> > support for GIL management at all, and it really ought to. This was
> > one of the things that was discussed in the BPL v3 discussions on
> > this list a few months ago.
> >
> He
On 16 Mar 2012 at 12:57, Adam Preble wrote:
> Well the current design does have a problem, but I think it's more to do
> with the Python side than the sum of the whole thing.
If by "Python side" you mean Boost.Python, then I agree: BPL has no
support for GIL management at all, and it really ough
The key to avoiding deadlocks is, in every case, the appropriate
design.
In what you posted you appear to be doing too much at once, so you're
holding onto too many locks at once. Either replace those with a
single, master lock or try to never hold more than one lock at any
one time. That incl
On 21 Feb 2012 at 16:46, VáclavSmilauer wrote:
> > 128 *byte* alignment? Wow. No, no compiler will support that legally
> > as it would crap all over your stack frame. I vaguely remember that
> > GCC caps alignment to 40 bytes due to some supported architecture's
> > stack frame being incapable
On 21 Feb 2012 at 16:30, Jonathan WRIGHT wrote:
> Boost python is being compiled in .obj files and then the whole lot is
> linked into a .pyd.
>
> Do you have some unit tests we could use to check our builds for
> problems? I've not understood how the dll linking requirement works.
> Where sho
On 21 Feb 2012 at 10:39, VáclavSmilauer wrote:
> > Aligning to 128 bits is surely __attribute__((__aligned__(16)))?
>
> Oops, I wrote it wrong in the title, it is 128-bytes aligned, double[16] with
> natural alignment, i.e. __attribute__((aligned(128))).
>
> Thanks for comments, I will try to pu
ally wondering what on earth is behind the tss issue and
> whether there is a simple test case to see if we are doing it right.
> Would something like a little function which creates and destroys
> threads show a memory leak if the tss is not right?
>
> Thanks,
>
> Jon
>
Generally when I see that missing symbol it means mismatched C
runtimes. Usually in my experience it's safe to declare that symbol
as weak to make the link error go away while handling if it's present
correctly.
Niall
On 20 Feb 2012 at 20:02, Jon Wright wrote:
> Hello,
>
> I have been trying
Aligning to 128 bits is surely __attribute__((__aligned__(16)))?
You also can inherit from an aligned base class even if that base
class contains no items and the alignment passes down just fine.
BTW alignment isn't reliable as soon as something leaves static
storage e.g. goes through a paramet
On 10 Feb 2012 at 21:23, Jim Bosch wrote:
> > when I execute Boost.Python export statement in C it adds some records in
> > Boost.Python and Python interpreter. When C is unloaded from memory somehow
> > these records are not being cleaned up. By the time we get to clean this
> > records
> > C is
On 2 Feb 2012 at 6:00, Davidson, Josh wrote:
> Neil, great information, but I did track this problem down to a quirk with
> Py++.
> [snip]
> After finding references to this problem as far back as 2006, I decided
> to switch over to balanced_split_module. This has its own set of
> problems. The
On 31 Jan 2012 at 16:44, Davidson, Josh wrote:
> Ok, well I did figure out the discrepancy between these extensions and
> previous extensions that have been built that required setting
> RTLD_GLOBAL. What I'm doing for these extensions is instead of building
> in all of the original C++ code AND
On 30 Jan 2012 at 1:21, Davidson, Josh wrote:
> Similar behavior, but now the storage import is FUBAR. Does anyone
> understand what is going on here?
>
> I'm using x64 Python 2.6.6 on x64 RHEL 6. Gcc version 4.4.6.
It's never popular for me to say this, but shared libraries really
aren't im
On 24 Jan 2012 at 9:32, Anders Wallin wrote:
> >> 5) I also read that Boost.Python is not thread safe, is that true and if
> >> yes can it be fixed/hacked ?
Not thread *aware* would be more accurate.
> > Other people on this list know a lot more than I do about this topic. I
> > believe the ans
Shouldn't you be wrapping a managed pointer to your C++ instance?
That stages the destruction properly by keeping the virtual function
table around long enough to call a virtualised destructor.
Search the archives of this mailing list. There are lots of examples.
Niall
On 24 Nov 2011 at 0:07,
On 21 Nov 2011 at 13:16, Stefan Seefeld wrote:
> >> I was wondering if it's possible to hook python functions as slots into
> >> boost::signal or boost::signal2 signals? I found an old thread that said
> >> it wasn't directly possible, but it was from 2004.
> >>
On 21 Nov 2011 at 9:08, Jay Riley wrote:
> I was wondering if it's possible to hook python functions as slots into
> boost::signal or boost::signal2 signals? I found an old thread that said
> it wasn't directly possible, but it was from 2004.
>
Integrating t
On 15 Nov 2011 at 10:00, Olivier Voyer wrote:
> What if I have this big C++ project that I cannot split in multiple smaller
> projects? I have no choice but to create a big Python module exposing all
> the functions/classes? What is the common practice?
You are aware, I assume, that the python wr
OS X 10.6 and later have a very aggressive memory allocator in them -
it is superbly quick, but it's still quite young code.
If your BPL example runs under valgrind on Linux fine - and I would
suspect that it does - it'll be a bug in either OS X or Apple's port
of GCC to OS X (which would hardl
On 5 Oct 2011 at 11:30, Dave Abrahams wrote:
> > I think this might turn into something that approaches the same mass
> > of complexity Niall describes,
>
> Nothing ever needs to be quite as complex as what Niall describes ;-)
>
> (no offense intended, Niall)
And here I am thinking I am clear
On 5 Oct 2011 at 9:18, Jim Bosch wrote:
> I think this might turn into something that approaches the same mass of
> complexity Niall describes, because a Python module can be imported into
> several places in a hierarchy at once, and it seems we'd have to track
> which instance of the module is
On 5 Oct 2011 at 7:21, Dave Abrahams wrote:
> >> I'd like to see support for static, template-based conversions. These
> >> would be defined by [partial-]specializing a traits class, and I tend to
> >> think they should only be invoked after attempting all registry-based
> >> conversions.
> >
On 3 Oct 2011 at 11:13, Dave Abrahams wrote:
> > I'd also say personal bug trackers are much more of a
> > design/development tool than a deployment/support tool. They're
> > really a type of post-it note tied into the repository.
>
> I'd like to try it. But now, suppose you have a project on
On 3 Oct 2011 at 8:34, Dave Abrahams wrote:
> Last time I looked at BE it was not really ready for primetime. You're
> motivating me to check it out again.
>
> *checks it out*
>
> Hmm... not sure this will get beyond the personal, though: it lacks so
> much of what people have come to expect, l
On 20 Sep 2011 at 12:38, Jim Bosch wrote:
> I'd also considered having a different set of template conversions that
> are checked first for performance reasons, but I'd actually viewed the
> override preference argument from the opposite direction - once a
> template converter traits class has
On 19 Sep 2011 at 17:03, Jim Bosch wrote:
> I'd like to see support for static, template-based conversions. These
> would be defined by [partial-]specializing a traits class, and I tend to
> think they should only be invoked after attempting all registry-based
> conversions.
Surely not! You'
If you're building stock using bjam, and it's failing, it's a bug :)
See if there's anything similar at
https://svn.boost.org/trac/boost/search?q=python&noquickjump=1&ticket=
on and if not, report it.
Sorry can't help much more personally. I haven't used BPL, or Boost
for that matter, in over f
If I am understanding you correctly, your attempts to build and/or
use stock BPL is failing when building the quickstart demo?
If so, there is surely some issue with your build environment as
Boost runs a series of automated regression tests which catch build
failures.
If I'm not right in unde
On 30 Aug 2011 at 10:42, Jim Bosch wrote:
> I agree with all of the above, and these could all be solved by my
> proposal of having per-module registrations take precedence over gloal
> registrations. Having a single optimal converter is clearly the best
> solution when such a thing exists, an
On 27 Aug 2011 at 12:29, Dave Abrahams wrote:
> In that case, if I were you, I would actually start using Git with the
> modularized / CMake-ified Boost at http://github.com/boost-lib.
If you do go for git, I have found repo embedded per-branch issue
tracking (e.g. http://bugseverywhere.org/) to
On 25 Aug 2011 at 13:59, Jim Bosch wrote:
> - For other Boost.Python experts on this list: do you have existing code
> or development time you'd like to contribute?
Firstly, I must commend you as you're a better man than I for
initiating this. I mostly chase money these past few years, and I
d
You're going to have to give a lot more information than this for
anyone to help you. In particular, a highly reduced and short example
of code exhibiting the problem would be very helpful.
Niall
On 20 Jun 2011 at 2:20, charles75 wrote:
> Hi,
>
> OS: UBUNTU 11.04
>
> Could someone please hel
On 9 Jun 2011 at 16:10, Jon McAuliffe wrote:
> when a thrown c++ exception is translated to the python layer
> and ultimately printed out by the python interpreter, is there
> an easy way to print out the corresponding c++-layer stack trace
> as well?
Easier on GCC than MSVC. See FXException::ini
> > Or you could stick with an older version of Mingw and wait till
> > someone else fixes the problem. Or use MSVC.
>
> Not really an option; GCC 4 gave us a factor 3 performance improvement
> over GCC 3, which we really need, and we're not really MSVC people.
Ah that's a useful clue - I patche
On 10 Jun 2011 at 16:03, Jérôme Laheurte wrote:
> > Might this be a symbol visibility problem?
>
> How can I check that ? I just tried #defining
> BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY in boost/python/detail/config.hpp
> and rebuilt the whole stuff but there's no difference.
I have little exp
Might this be a symbol visibility problem?
Niall
On 10 Jun 2011 at 14:16, Jérôme Laheurte wrote:
> On 06/07/2011 09:59 AM, Lars Viklund wrote:
>
> > On Tue, Jun 07, 2011 at 09:40:25AM +0200, Jérôme Laheurte wrote:
> >> Hello. I already asked this on StackOverflow but it doesn't seem to
> >> in
On 14 Dec 2010 at 14:07, Jacob Davis wrote:
> I read through the thread back when I started work on this problem, but
> figured if it had been scrubbed out it might not be wise to use it. I'll go
> back and check it out soon, though.
Trampoline types are a very commonly used idiom in C++
metapro
On 12 Dec 2010 at 14:02, Jacob Davis wrote:
> I'm wrapping a C libary with Boost Python and having a really difficult time
> with void * typedefs. For example, here's a typedef and the function header
> that uses it:
>
> typedef void * EmoEngineEventHandle;
> EmoEngineEventHandle EE_EmoEngineEven
Have you checked to ensure your applications meet the criteria
specified in http://www.nedprod.com/programs/gccvisibility.html?
Usually this problem is due to a failure to fully implement this. Or
it's a bug in GCC :)
Niall
On 2 Dec 2010 at 18:05, Charles Solar wrote:
> This happens in my app
On 19 Aug 2010 at 14:10, Gustavo Carneiro wrote:
> See also: WAF http://code.google.com/p/waf/
>
> It is also in Python, but is a lot faster than scons. It has some usability
> problems (but scons does have them too), but it's a pretty useful tool to
> know...
That is a very useful link indeed
On 18 Aug 2010 at 15:32, David Aldrich wrote:
> > I would strongly recommend that you use something more modern than
> > GNU make. Boost's build system is much better. The one I use is scons
> > (http://www.scons.org/) whose only main fault is O(N^2) scaling to
> > source file number, a problem th
On 17 Aug 2010 at 14:20, David Aldrich wrote:
> I would be grateful for some help with setting up some makefiles for my
> C++ application, compiled with gcc under Linux, that uses Boost.Python.
I would strongly recommend that you use something more modern than
GNU make. Boost's build system is
On 30 Jul 2010 at 11:38, Ralf W. Grosse-Kunstleve wrote:
> > Your best bet it would seem now is to have PATH
> > modified on app install, but that is a very lazy way out and is
> > indeed banned in lots of corporate environments.
>
> I solved this problem via a small launcher executable. It is j
On 30 Jul 2010 at 10:56, David Aldrich wrote:
> > I thought that the application installer registered the DLL manifests
> > at their locations? It's like registering COM or .NET objects, in
> > fact I think it's the same mechanism nowadays.
>
> Well, I don't plan to use an application installer.
On 30 Jul 2010 at 8:22, David Aldrich wrote:
> Thanks for your reply. I have now succeeded in creating a manifest file
> for an assembly that includes the boost_python dll's. But I don't
> understand how to specify a non-default location for the assembly using
> that manifest. I believe this is do
On 29 Jul 2010 at 12:09, David Aldrich wrote:
> > Wouldn't using an embedded manifest to specify a non-default DLL location
> > be much easier?
>
> Thanks. I am not familiar with how that works. Please can you give me any
> tips on how to do this?
Searching MSDN or Google would give you all th
Wouldn't using an embedded manifest to specify a non-default DLL
location be much easier?
Niall
On 29 Jul 2010 at 11:26, David Aldrich wrote:
> Hi
>
> I am working on a Windows application that uses boost_python, linked with
> shared libraries.
>
> I need to store the boost_python dll in a f
On 23 Jul 2010 at 13:56, Jim Bosch wrote:
> Given that many people (including myself) have pickled Boost.Python
> objects inside dicts many times before without issue, it might be tricky
> to make a contained example that reproduces it this problem. And I'm
> less motivated now because I can j
On 23 Jul 2010 at 9:49, Stefan Seefeld wrote:
> On 07/23/2010 09:35 AM, Niall Douglas wrote:
> > I would even go so far as to say that RTLD_LOCAL
> > needs deprecating in GNU libc.
>
> That would open the door for all sorts of ABI issues (symbol collisions
> result
1 - 100 of 118 matches
Mail list logo
