On Thu, 07 Sep 2006 07:16:46 -0700, durgaprasad jammula wrote:
> Hi All,
>
> I want to make a shared library which should also be an executable. Can
> you please tell me how to do it.
It used to be kind of a pain to do this, these days you can probably
dlopen PIE binaries, or statically link in
On Mon, 24 Apr 2006 15:27:07 -0400, Nicolas De Rico wrote:
> I would like to compile files created on Windows and encoded in
> "Unicode" (UTF-8 or UTF-16). Microsoft puts a little header at the
> beginning of files to indicate that they are UTF-16, UTF-8, etc. I
> believe that this header is s
Hi,
A while ago I brought up the subject of C++ inlined symbols conflicting
inside a process image due to them having ELF global scope:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
Template inlines have global visibility
It seems there's now been a sort of fix, at least for libstdc++,
On Fri, 18 Nov 2005 17:50:52 -0800, Chris Lattner wrote:
> Recently, at Apple, I have been working on a new version of the llvm-
> gcc translation layer, built on GCC 4 ... I plan to have this work
> committed to the Apple branch within a month.
I'm curious as to why Apple is doing this. Is it s
On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote:
> 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.
I hadn't seen th
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
On Sun, 19 Jun 2005 15:06:58 +0200, Paolo Carlini wrote:
> The issue that Benjamin just fixed is very simple to explain (much less
> to fix ;) : some recently added exported symbols had the default v6
> version, that is, 3.4.0, instead of 3.4.5.
Ah I see :)
Are the new symbols new APIs, or will
On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote:
> I'm testing a patch that resolves the issue. I expect to have additional
> details within 24 hrs, and will let you know details.
Is this bug #21405, or some other versioning issue?
thanks -mike
On Thu, 09 Jun 2005 15:47:31 +0200, Marcin Dalecki wrote:
> NTPL vers. non NTPL signal handling differences. The FC3 compiler contains
> some "backward compatibility" shims at quite a few places, which are
> allowing old binaries to execute. However stuff compiled with the FC3
> version of the comp
On Fri, 20 May 2005 19:24:07 +0100, Dave Korn wrote:
> Absolutely so, no problem
Absolutely not, there will be lots of problems. This whole thread is about
how you *can't* just do that. Your app still won't run on older systems
(reliably) even if you target old APIs and use dlopen for the rest. Th
On Thu, 19 May 2005 18:15:33 -0700, David Daney wrote:
> The point here is what happens when you do build-time linking to
> functions that don't exist in older versions of the system's shared
> libraries (those linked at runtime).
Actually that's not the point here. This is an easy problem to no
On Thu, 19 May 2005 16:38:12 +0200, Marcin Dalecki wrote:
> Ah I see. You live under the perhaps marketing inflicted self delusion
> that Linux/x86 denominates a single well defined system.
> Welcome to the reality then.
99% of the time, it does. The fact that in a few areas it doesn't is
somethin
On Wed, 18 May 2005 22:02:37 +0100, Paul Brook wrote:
> Rubbish. You've obviously never tried to install two third party windows
> applications that require two different revisions of msvcrt.dll, or even
> worse two random versions of an OCX control.
And Linux has dependency hell.
As a long ti
On Wed, 18 May 2005 14:29:12 -0700, Joe Buck wrote:
> These kinds of problems can be solved, but they are beyond the scope of
> this list.
Well, alright - but which list is it in scope for? GCC is generally pretty
good about this but in a few parts where it interacts with glibc like the
EH code, v
On Wed, 18 May 2005 17:26:30 +0200, Marcin Dalecki wrote:
> Like building on the system you are targeting?
> Like cross building for the target system?
No, like messing around with headers and linkers and compilers, so if you
are targetting Linux/x86 your binaries can in fact run on Linux/x86.
I
On Wed, 18 May 2005 10:05:34 -0700, Dan Kegel wrote:
> No hacks needed; you just have to embrace reality.
The reality is that 95% of computers run Windows which is very good at
supporting developers who distribute binaries in this way. On Linux
there's all kinds of gotchas you just Have To Know wh
On Wed, 18 May 2005 15:13:41 +0200, Jakub Jelinek wrote:
> Compiler built in presence of dl_iterate_phdr creates binaries and shared
> libraries, that rely on its presence in target glibc, as support code
> for older glibc's is intentionally left out in that case.
Why is that? Is the support code
On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
> If I build main with C1, and libf.so with C2, and execute the program so
> that it uses C2's libgcc_s.so.1, it works.
Out of interest, what happens if you build main with C2 and libf with C1?
That would seem to be a more common situati
Hi,
I finally got time (darn exams!) to file a bug on this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
This is the bug where two libs in the same ELF image compiled using
different C++ ABIs can interfere even when not linked to each other,
because the compiler emits symbols from the STL
On Sun, 2005-04-17 at 19:22 -0700, Dan Kegel wrote:
> But I can't shake the feeling that it's crazy that libaspell
> got linked against two different C++ libraries. Can you
> try creating a minimal test case demonstrating this
> without involving inkscape? If so, maybe it's a glibc
> shared libra
On Sat, 16 Apr 2005 21:30:55 -0700, Joe Buck wrote:
> Do we really promise somewhere that this will work? I know that we warn
> in other places that it probably will not.
Yes, see the "Testing Multi-ABI binaries" section here:
http://gcc.gnu.org/onlinedocs/libstdc++/abi.html
> Yes, symbol versi
Hi,
I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4
based system. All of the C++ libraries it links directly against, like
GTKmm, are statically linked. In other words, it dynamically links
against no C++ libraries.
Inkscape dlopens libgtkspell, which in turn dlopens libaspe
Hi,
When using FORTIFY_SOURCE I think some new symbols are required from very
recent glibcs. This makes sense when you are compiling binaries just for
your own system or distribution but it'd be nice to be able to statically
link this code (the *_chk functions etc) so fortified binaries can be run
On Sun, 2005-02-27 at 08:21 -0800, Dale Johannesen wrote:
> Current patches of this nature include the inclusion of strict-
> aliasing in -O2, writable strings, and casts as lvalues, and I'm sure
> there are others. (So if you really want any of those, you can pick
> it up from Apple's branch:) I
Hello,
I have just finished fixing up a piece of code dating from around 2001
which was quite badly broken by the incompatible change of __FUNCTION__ to
no longer operate as a preprocessor constant.
Unfortunately this codebase is riddled with constructs like
fatal_error(__FUNCTION__": foo");
25 matches
Mail list logo
