Mike Hearn wrote:
On Mon, 17 May 2004 04:05:51 +0200, Guido Draheim wrote:
gcc supports the universal attribute syntax, and it does now know about more
symbol flavours as to their visibility. Probably you want to have "hidden".
Attached are two simple test*.c files and a makefile. The final shared
Yay! Now everyone's happy! Group hug everyone!
/was a tenny bit worried about losing commercial
intrest because we simply use ELF executables.
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
> On Mon, 17 May 2004 04:05:51 +0200, Guido Draheim
> wrote:
> > gcc supports the universal attribute syntax, a
On Mon, 17 May 2004 04:05:51 +0200, Guido Draheim wrote:
> gcc supports the universal attribute syntax, and it does now know about more
> symbol flavours as to their visibility. Probably you want to have "hidden".
> Attached are two simple test*.c files and a makefile. The final sharedlib
> symbol
sorry, just saw the note on WWN. I did hope that there would be someone
to point to the gcc visibility stuff already - but it seems that people are
more concerned to exchange their believes and politics rather showing
off some engineering stuff.
* preface:
it's not in the file format - it's in the
On Sat, 15 May 2004 12:39:51 -0700, Dan Timis wrote:
> Actually, we do have an encryption system, and it is the name of the
> functions used internally by the encryption library that we want to
> hide. It is not for hiding trade secrets, but to prevent dishonest
> customers from accessing featu
From: Mike Hearn <[EMAIL PROTECTED]>
Subject: Re: symbol hiding
Date: Sat, 15 May 2004 17:07:15 +0100
Organization: CodeWeavers, Inc
I think Pauls point was that if what you are doing is so secret and so
proprietary that you're afraid symbol names will leak trade secrets
you're
Thank you Paul and Brian,
I thought it was probably OK to ask these kind of questions. But, it's
nice to know for sure.
Dan
On Fri, 14 May 2004 16:02:20 -0700, Dan Timis wrote:
> If questions relating to a commercial non open source product that uses
> wine heavily are not welcome on this list, I apologize and I will never
> ask these kinds of questions again.
Given that 99.9% of the software Wine is used to run
>My original question generated this new thread, which in turn became
>very technical. But, I think that Paul's original posting was more of
>a philosophical or maybe even moral nature.
[ ... ]
>If questions relating to a commercial non open source product that uses
>wine heavily are not we
On Friday, May 14, 2004, at 05:34 AM, [EMAIL PROTECTED]
wrote:
Message: 5
Date: Thu, 13 May 2004 22:26:34 -0400
From: Paul Davis <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: symbol hiding
for this reason, i personally wouldn't feel comfortable asking in a
public forum how to go
On Fri, 2004-05-14 at 23:58 +0900, Dmitry Timoshkov wrote:
> ELF versioning is just another attempt to hide problems instead of
> fixing the source of it IMHO. Exactly for this reason even simple
> 'Hello World' program compiled under RH 9.0 will not run under RH 6.2.
What exactly are the problems
"Mike Hearn" <[EMAIL PROTECTED]> wrote:
> > Can you list at least some things you think are bad in PE in comparison
> > with ELF?
>
> Sure - ELF has decent versioning, which PE lacks and has caused massive
> pain due to conflicts etc. While you can rename DLLs on Windows it's not
> a part of the
Erik de Castro Lopo wrote:
On Fri, 14 May 2004 14:24:51 +0100
James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
What is wrong with seeing names of internal interfaces?
The main problem is the likelihood of symbol collisions between
internal symbols which are the same in two different libraries.
On Fri, 14 May 2004 14:24:51 +0100
James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
> What is wrong with seeing names of internal interfaces?
The main problem is the likelihood of symbol collisions between
internal symbols which are the same in two different libraries.
By restricting the export
Dmitry Timoshkov wrote:
Also, I personally feel a bit not comfortable when someone (for any
reason) is looking into a binary and sees names of internal interfaces
not appropriate for external learn/use. I find it ugly that I can't fully
control such basic things in the ELF world.
What is wrong wi
On Fri, 2004-05-14 at 21:53 +0900, Dmitry Timoshkov wrote:
> Can you list at least some things you think are bad in PE in comparison
> with ELF?
Sure - ELF has decent versioning, which PE lacks and has caused massive
pain due to conflicts etc. While you can rename DLLs on Windows it's not
a part
"Mike Hearn" <[EMAIL PROTECTED]> wrote:
> > Sigh, I still think that ELF is inherently sick, and inventing new (intrusive)
> > workarounds makes it even worse.
>
> Maybe. But let's face it, the alternatives aren't much better. The only
> real competition is PE (Windows) which is worse than ELF i
On Fri, 2004-05-14 at 21:33 +0900, Dmitry Timoshkov wrote:
> It's even uglier. Instead of resolving the problem that guys decided
> just to hide it.
It's not necessarily bad. The information being there may be ugly, but
it *can* be useful. If we didn't have that, we'd be unable to use the
pthread
"Mike Hearn" <[EMAIL PROTECTED]> wrote:
> > Also, I personally feel a bit not comfortable when someone (for any
> > reason) is looking into a binary and sees names of internal interfaces
> > not appropriate for external learn/use. I find it ugly that I can't fully
> > control such basic things in
On Fri, 14 May 2004 13:29:48 +0900, Dmitry Timoshkov wrote:
> Also, I personally feel a bit not comfortable when someone (for any
> reason) is looking into a binary and sees names of internal interfaces
> not appropriate for external learn/use. I find it ugly that I can't fully
> control such basic
"Paul Davis" <[EMAIL PROTECTED]> wrote:
> >> for this reason, i personally wouldn't feel comfortable asking in a
> >> public forum how to go about doing this. your mileage may and probably
> >> does vary, of course.
> >
> >Well, if I could clearly predict ELF linker behaviour with several
> >diffe
>> for this reason, i personally wouldn't feel comfortable asking in a
>> public forum how to go about doing this. your mileage may and probably
>> does vary, of course.
>
>Well, if I could clearly predict ELF linker behaviour with several
>different modules each having global variables/functions w
"Paul Davis" <[EMAIL PROTECTED]> wrote:
> i'd just like to mention a small concern i have.
>
> hiding symbols might well be a perfectly honest thing to want to do. i
> personally can't see why, since a list of symbol names doesn't provide
> much extra help to somebody who wants to disassemble and
i'd just like to mention a small concern i have.
hiding symbols might well be a perfectly honest thing to want to do. i
personally can't see why, since a list of symbol names doesn't provide
much extra help to somebody who wants to disassemble and reverse
engineer your code. but i can understand t
24 matches
Mail list logo
