Jonathan Wilson kirjoitti:
> Neither does Linux - by linking against a recent library you are
> *asking* for a binary that requires that library. If you understand
> that you might understand why everyone is saying you should build on
the
> lowest common denominator of the systems you're targ
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
Original Message
>From: Jonathan Wilson
>Sent: 20 May 2005 00:07
> On windows, it is possible to build a binary using a compiler on Windows
> XP that can then run on older versions of windows simply by not using any
> features specific to the newest versions of windows XP (or by using
> L
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
Jonathan Wilson wrote:
On windows, it is possible to build a binary using a compiler on Windows
XP that can then run on older versions of windows simply by not using
any features specific to the newest versions of windows XP (or by using
LoadLibrary and GetProcAddress to see if those features ar
> Neither does Linux - by linking against a recent library you are
> *asking* for a binary that requires that library. If you understand
> that you might understand why everyone is saying you should build on the
> lowest common denominator of the systems you're targetting.
>
> If you insist on shi
On Thu, May 19, 2005 at 04:42:42PM +0100, Mike Hearn wrote:
> 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% o
On Thu, May 19, 2005 at 02:28:46PM +0100, Mike Hearn wrote:
> 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 t
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 Thu, May 19, 2005 at 02:22:42PM +0100, Mike Hearn wrote:
> 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 versi
On 2005-05-19, at 15:18, Mike Hearn wrote:
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 bi
> "DLL hell" is a Windows term, not a Unix/BSD/GNU/Linux term, for a
reason.
Unix would have "SO woes".
Paolo
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
Mike Hearn <[EMAIL PROTECTED]> writes:
> The reality is that 95% of computers run Windows which is very good at
> supporting developers who distribute binaries in this way.
Does it? I constantly hear horror stories of apps delivering their own
version of system libraries that cause all kinds of
On Wed, May 18, 2005 at 11:08:30PM +0200, Paolo Carlini wrote:
> Paul Brook wrote:
>
> >In my experience most windows applications work because they're either
> >statically linked, or ship with a copy of every single library they need.
> >
> >
> Well, sorry for contributing to the flame, but I
On Wed, May 18, 2005 at 09:33:35PM +0100, Mike Hearn wrote:
> 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 th
On Wed, May 18, 2005 at 09:27:50PM +0100, Mike Hearn wrote:
> The biggest problem really is that this sort of thing is a lot of effort
> for your average evenings-and-weekends open source hacker who wants to
> distribute Linux binaries to his end users. Setting up and maintaining a
> dedicated buil
Paul Brook wrote:
>In my experience most windows applications work because they're either
>statically linked, or ship with a copy of every single library they need.
>
>
Well, sorry for contributing to the flame, but I have the very *same*
feeling. The only reason why I'm publically stating this
On Wednesday 18 May 2005 21:33, Mike Hearn wrote:
> 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
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
[EMAIL PROTECTED] wrote:
> [ Things break horribly when I compile them
> with a compiler built against glibc-2.3.x
> and try to run them on a glibc-2.2.x system. ]
This is expected and normal. gcc and glibc have
circular dependencies. A gcc tainted with a newer
glibc is expected to produce bi
On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:
> 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 mai
On 2005-05-18, at 14:36, Mike Hearn wrote:
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?
T
On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:
> Could there please at some point be serious discussion of making this a
> supported way of working? In this case dl_iterate_phdr is weak so could
> the decision about whether to use it or not could be made at runtime, not
> build time?
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
Stephan Bergmann <[EMAIL PROTECTED]> writes:
> If I build main with C1, and libf.so with C2, and execute the program so
> that it uses C1's libgcc_s.so.1, it aborts.
Forward compatibility is never guaranteed. If you want to execute on the
older system you need to build all parts on the older sy
Hi all,
I experience the following problem on Linux x86:
I have one version of GCC, call it C1, compiled on a glibc 2.2 (plain
2.2, that is) machine. (It happens to be GCC 3.4.1, but the exact
version is probably irrelevant.) This build includes a version of
libgcc_s.so.1.
Additionally, I hav
30 matches
Mail list logo
