On Thu, Apr 27, 2006 at 05:16:10PM -0700, Joe Buck wrote:
> On Thu, Apr 27, 2006 at 07:58:29PM -0400, Zack Weinberg wrote:
> [ Unicode, UTF-{8,16}, BOMs, etc ]
> > It would also be good to take advantage of the fact that 95+% of C
> > source files start with "/*", "//", "#i", or "#d" to distinguish
On 4/28/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On Apr 27, 2006, at 10:46 AM, Qiuker wrote:
> I'm trying to support Shared libraries on mcore. but it doesn't
> support PIC. So, need I add PIC first?
Only if your shared library design requires it. Some don't. You
probably will need to.
> Is
[ Unicode, UTF-{8,16}, BOMs, etc ]
On Thu, Apr 27, 2006 at 07:58:29PM -0400, Zack Weinberg wrote:
> complicated) "Local Variables:" marker near the end of the file;
> other editors have similar, but of course incompatible, conventions
> (I know Vim has one but I don't know what it looks like). It
> I think that CPP should try to determine the encoding for each file
> and not use a single encoding for every file. It should look for
> a unicode header when it opens a file (original c source or any
> include), and if it doesn't find one, use the default: -finput-charset,
> LC_CTYPE, UTF-8, un
Snapshot gcc-4.0-20060427 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060427/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Dear List,
do you all remember this?
Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html
if your memory needs to be jogged.
One month and a few hours on... has anything changed? Is
Gabriel Dos Reis still looking into this, or has he been hit
by a bus?
Bernard Leak
--
A man
Mike,
Indeed this is a bug in the linker on MacOS X. Read...
http://gcc.gnu.org/ml/gcc/2006-04/msg00523.html
When the arch is set to ppc64, the error...
ld: foo.o has local relocation entries in non-writable section (__TEXT,__text)
doesn't occur and non-PIC code is silently linked into a sha
On Apr 26, 2006, at 6:26 PM, Jack Howarth wrote:
readelf -d foo.so | grep TEXTREL
Does anyone know if some mechanism like this is possible for Darwin
shared libraries?
A man page is a terrible thing to waste:
-segprot name max init (32-bit only)
Specifies the maximum and
On Apr 27, 2006, at 10:46 AM, Qiuker wrote:
I'm trying to support Shared libraries on mcore. but it doesn't
support PIC. So, need I add PIC first?
Only if your shared library design requires it. Some don't. You
probably will need to.
Is there any info for adding it?
The usual referenc
Hello,
I'm trying to support Shared libraries on mcore. but it doesn't
support PIC .
So, need I add PIC first? Is there any info for adding it?
Thx
Qiuke
On Thu, Apr 27, 2006 at 10:50:07AM +0100, Andrew Haley wrote:
> x86 is special. On x86 it's somewhat possible to build shared
> libraries without PIC, but it's a really bad idea. On other arches,
> PIC is compulsory. So:
>
>
> [EMAIL PROTECTED] ~]$ /usr/bin/gcc -m32 -shared -o client.so client
I've downloaded the gcc-4.1.0.tar.gz file from several different mirrors
as well as ftp.gnu.org and the MD5 checksum does not verify. I
downloaded gcc-4.0.3.tar.gz without problem.
Can you please provide a good link to the 4.1.0 tarball.
Thanks
Brian Showalter
Software Engineer
DRS Intelligen
Jack Howarth writes:
> What on earth would make you think that the linker on Darwin
> would reject non-PIC code in linking a shared library. The linker
> on Linux doesn't do any such thing (hence the discussion on the
> Debian mailing list of adopting this as check on their builds).
x86 i
On 4/27/06, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Andrew,
> What on earth would make you think that the linker on Darwin would
> reject non-PIC code in linking a shared library. The linker on Linux
> doesn't do any such thing
It does (at least on some archs):
/usr/lib64/gcc/x86_64-suse-li
14 matches
Mail list logo
