I have a system that uses some shared libraries. I find that
when a library constructor runs the __wrap_main() did not
yet execute and as a results I get many violations on the
objects that it registers.
The attached program demonstrates 'stderr' (simple to do)
but my main problem is 'environ' whi
I was avoiding using mudflap for a while due to the high volume
of violations that I could not explain. Recently, they all
disappeared which made me happy and I started using mf. I got
zero violations since.
When I had time to think about it I figured this just cannot
be true.
I have now confirme
I am trying to build xplor-nih on MacOS X 10.4 using gcc 4.1.0
branch's gcc and g++ instead of Apple's and am running into a really
strange error. I find the following linkage fails...
g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o
libswigpy-xplor.dylib -o _xplorWrap.so
-L/Use
Eyal Lebedinsky wrote:
> I have a system that uses some shared libraries. I find that
> when a library constructor runs the __wrap_main() did not
> yet execute and as a results I get many violations on the
> objects that it registers.
The attached patch seems to work for me, is it proper?
It regi
[EMAIL PROTECTED] (Jack Howarth) writes:
>I am trying to build xplor-nih on MacOS X 10.4 using gcc 4.1.0
> branch's gcc and g++ instead of Apple's and am running into a really
> strange error. I find the following linkage fails...
>
> g++-4 -bundle -flat_namespace -undefined suppress _xplorWra
I am investigating unusual results from mudflap tests. I added a some
test lines to my program to provoke violations and found that auto
variables are not checked correctly inside threads.
Attached is a test program that demonstrates the problem. It runs the
same code in main (and gets the two exp
On 29 Jul 2005, Florian Weimer announced authoritatively:
> * michael meeks:
>
>> I've been doing a little thinking about how to improve OO.o startup
>> performance recently; and - well, relocation processing happens to be
>> the single, biggest thing that most tools flag.
>
> Have you tried
michael meeks <[EMAIL PROTECTED]> wrote:
> I've been doing a little thinking about how to improve OO.o startup
> performance recently; and - well, relocation processing happens to be
> the single, biggest thing that most tools flag.
>
> Anyhow - so I wrote up the problem, and a couple of potential
Andreas,
Are you sure gnu gcc shouldn't support this? I see -bundle under the
Machine Dependent Options under Darwin options which are not marked as
APPLE-ONLY. I understood that to mean that it should be present in the
gnu gcc compiler (like -all_load which is in the same list and is
support
>
> Andreas,
> Are you sure gnu gcc shouldn't support this? I see -bundle under the
> Machine Dependent Options under Darwin options which are not marked as
> APPLE-ONLY. I understood that to mean that it should be present in the
> gnu gcc compiler (like -all_load which is in the same list an
MM wrote in http://go-oo.org/~michael/OOoStartup.pdf:
"... not one slot was overridden by an implementation
method external to the implementing library."
Hmm. For some reason that reminds me of the 'final'
keyword which is periodically proposed
(e.g. http://gcc.gnu.org/ml/gcc/2004-02/msg01483.htm
I can't find a patch either using google but I did find the following
posting which describes the problem and a workaround...
http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg10604.html
Jack
On Jul 30, 2005, at 11:52 AM, Jack Howarth wrote:
I can't find a patch either using google but I did find the
following
posting which describes the problem and a workaround...
http://www.mail-archive.com/fink-devel@lists.sourceforge.net/
msg10604.html
I finally found the patch:
http://
Here is another posting which describes the problem a little clearer...
http://lists.apple.com/archives/darwin-development/2003/Jun/msg0.html
So gcc needs to be fixed to not misparse -bundle, when it is the first
argument to gcc, as being the "-b Machine" target option.
Shouldn't the fix
Thanks. It applies with offsets to the current 4.0 branch. Hopefully we can get
it in both branches soon. Currently everyone on Darwin is just hacking their
Makefiles around the problem.
Jack
Hi everyone,
I am getting weird warning messages from my assembler when
gcov is being used. I have tracked what I think is the
problem down but I don't really know how to fix it. The
bit of assembler that causes the warning is:
.type .LPBX0, @object
.size .LPBX0, 52
.LPBX0:
... whole
Giovanni Bajo writes:
> michael meeks <[EMAIL PROTECTED]> wrote:
>
> > I've been doing a little thinking about how to improve OO.o startup
> > performance recently; and - well, relocation processing happens to be
> > the single, biggest thing that most tools flag.
> >
> > Anyhow - so I wrot
Snapshot gcc-4.1-20050730 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050730/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-07-30 17:43 UTC
You'll
> Jan,
Hi,
> That's going to be rather difficult given that the app
> has over 1000 files. Is there a way I can turn off the
> "default" options one at a time ?
This is unforutnately not possible :( The optimizations used either
profile feedback or profile guessed by GCC itself. It looks like fo
Kean Johnston <[EMAIL PROTECTED]> writes:
> I am getting weird warning messages from my assembler when
> gcov is being used. I have tracked what I think is the
> problem down but I don't really know how to fix it. The
> bit of assembler that causes the warning is:
>
> .type .LPBX0, @object
>
I don't understand why the .type and .size information is useless.
Becuase its for a local lable only, not anything thats intended
to wind up in the symbol table? I'm not sure what meaning a
type and size has for a local lable like that?
Kean
I don't understand why the .type and .size information is useless.
Just some further information ... gas thinks it's useless too.
The information is recorded in the object file. I've seen various
No, it's not. At least not with gas 2.15.90.0.3. Just is just
silent about it. The SCO assembler
Hi,
One problem with the parallel C++ ABI versioning (which makes it not so
useful) is that symbols in the libstdc++ namespaces are put into the
generated binary if you use the STL. Those generated symbols are *not*
symbol versioned so conflicts can still occur.
This is registered in bugzilla and
Kean Johnston <[EMAIL PROTECTED]> writes:
> > I don't understand why the .type and .size information is useless.
> Becuase its for a local lable only, not anything thats intended
> to wind up in the symbol table? I'm not sure what meaning a
> type and size has for a local lable like that?
Oh, I s
On Saturday, July 30, 2005, at 09:09 AM, Andrew Pinski wrote:
But I don't know what happened to it or came up from the discussion.
Looks like no response to Geoff's last comment. If someone wants to
address his stated concerns and resubmit it... otherwise, -Wl,-bundle
should do the trick.
On Sat, Jul 30, 2005 at 09:33:45PM +0100, Mike Hearn wrote:
> Hi,
>
> One problem with the parallel C++ ABI versioning (which makes it not so
> useful) is that symbols in the libstdc++ namespaces are put into the
> generated binary if you use the STL. Those generated symbols are *not*
> symbol ver
> You may wish to read the proceedings from this year's GCC summit, where
> another solution was presented by some gentlemen from Intel. For
> various reasons, symbol versioning is not a useful solution to this
> problem.
>
> No one objected to their solution in principle, AFAICT, although there
>
27 matches
Mail list logo
