Hi,
On Mon, May 02, 2005 at 06:09:04PM +0200, Matthias Klose wrote:
- which is the last version that built on hurd-i386?
According to ftp.debian.org, it appears to be 3.4.1-7, though I do not
remember exactly.
- does gcc-4.0 (experimental) build?
No, at least not out of the box. libffi
On Wed, 4 May 2005, Michael Banck wrote:
On Mon, May 02, 2005 at 06:09:04PM +0200, Matthias Klose wrote:
Anyway, back to the gcc-3.4 build log:
./xgcc -B./ -B/usr/i586-gnu/bin/ -isystem /usr/i586-gnu/include
-isystem /usr/i586-gnu/sys-include
On Wed, May 04, 2005 at 02:42:15PM +0200, Michael Banck wrote:
On Mon, May 02, 2005 at 06:09:04PM +0200, Matthias Klose wrote:
- which is the last version that built on hurd-i386?
According to ftp.debian.org, it appears to be 3.4.1-7, though I do not
remember exactly.
I was able to build
tags 301064 +patch
thanks
On Wed, May 04, 2005 at 03:48:07PM +0200, Thomas Schwinge wrote:
I was able to build und use gcc-3_4-branch (last month or so).
The only problem was (and still is) that _statically_ linked executables
are segfaulting immediatelly.
I was not yet able to debug that;
How about making gcc's configure test smart so that when you do
--prefix= (the normal way to configure any program for the GNU
system) it looks for headers in /include /local, and if you do
--prefix=/usr (as Debian does) it would look for the files in
/usr/include /usr/local?
This is the right
If /usr is a symlink to / and gcc uses /usr/include, it will work.
If /usr is a real directory and gcc uses /usr/include, it will work as well.
And if /usr doesn't exist, it will not work at all. Hard coding is
just bad, period.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
How about making gcc's configure test smart so that when you do
--prefix= (the normal way to configure any program for the GNU
system) it looks for headers in /include /local, and if you do
--prefix=/usr (as Debian does) it would look for the files in
/usr/include /usr/local?
#v+
# In GNU, /usr is a four-letter word.
NATIVE_SYSTEM_HEADER_DIR = /include
#v-
I think that just changing NATIVE_SYSTEM_HEADER_DIR to:
NATIVE_SYSTEM_HEADER_DIR = $(prefix)/include
would fix all problems, could someone with a GNU/Hurd system check
that? It would kinda break stuff
Santiago Vila, le Wed 04 May 2005 15:22:27 +0200, a dit :
* dpkg-shlibdeps needs to be patched and the build logs are full of
ugly junk when debian/rules reaches dh_shlibdeps.
I submitted a patch for this some time ago (and it should also solve
other troubles with x86_64), but it doesn't seem
Again, this should be a Debian-specific change for now.
It will be a Debian specific change forever.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
- which is the last version that built on hurd-i386?
- does gcc-4.0 (experimental) build?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
11 matches
Mail list logo
