https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #34 from Greg Chandler ---
With this set of debugs in gcc.cc:execute
/* Run each piped subprocess. */
fprintf (stdout, "Run each piped subprocess\n");
fprintf (stdout, "progname: %s\ntemp_filename: %s\n", progname, temp_filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #33 from Greg Chandler ---
for (n_commands = 1, i = 0; argbuf.iterate (i, &arg); i++)
fprintf (stdout, "%d: %s\n", i, argbuf[0]);
With the following inside the following if: if (arg && strcmp (arg, "|") == 0)
fprintf (stdo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #32 from Greg Chandler ---
Starting to get some progress
I added a print statement in gcc.cc to see what is being executed:
-> 3298 /*HERE*/
-> 3299 for (n_commands = 1, i = 0; argbuf.iterate (i, &arg); i++)
-> 3300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #30 from Greg Chandler ---
It's not the preprocessor:
root@bigbang:/tmp# gcc -E 1.c
root@bigbang:/tmp#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #31 from Greg Chandler ---
This hangs:
root@bigbang:/tmp# gcc -S 1.c
>From ps -faux:
root 391 0.0 0.1 4832 3912 ttyS0Ss 03:28 0:00 -bash
root 432 0.4 0.1 6616 2512 ttyS0S+ 03:57 0:00 \_ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #29 from Greg Chandler ---
I tried recompiling the native again with the absolute minimum, with debugging
to help try to track this down:
../configure \
--disable-analyzer \
--disable-bootstrap \
--disable-cet \
--disable-de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #28 from Greg Chandler ---
Everywhere I look at this problem, something doesn't look right, so I took the
drastic step of rebuilding everything. Beause nothing was matching up. Some
things had tls, some didn't, some had ld as gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120586
--- Comment #2 from Greg Chandler ---
(In reply to Andrew Pinski from comment #1)
> > --with-newlib
>
> You can't use that and then use glibc to build libstdc++.
>
> If you are building libstdc++ for the second stage, you should not have `
>
++
Assignee: unassigned at gcc dot gnu.org
Reporter: chandleg at wizardsworks dot org
Target Milestone: ---
I every time I try to build a native compiler with a cross, with
--enable-libstdc++ I run into this. I see it on all 14.x gcc versions.
glibc on the build host is 2.40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #27 from Greg Chandler ---
root@bigbang:/tmp# which as
/usr/bin/as
root@bigbang:/tmp# as -v
GNU assembler version 2.44 (alpha-linux-gnu) using BFD version version
2.44-slack151
^C
root@bigbang:/tmp# as 1.s
root@bigbang:/tmp# ls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #26 from Greg Chandler ---
root@bigbang:/tmp# /usr/libexec/gcc/alpha-linux-gnu/14.2.0/cc1 /tmp/1.c
__bswap_16 __bswap_32 __bswap_64 __uint16_identity __uint32_identity
__uint64_identity main
Analyzing compilation unit
Performing int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #25 from Greg Chandler ---
ctrl-d at that read yielded this:
read(0, "", 8192) = 0
close(0)= 0
times({tms_utime=12 /* 0.012 s */, tms_stime=11 /* 0.011 s */, tms_cutime=0,
tms_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #24 from Greg Chandler ---
I took another look at the strack trace, comparing it to the cross-compiler on
the build system.
Build system:
newfstatat(AT_FDCWD,
"/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/include",
{st_mode=S_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #23 from Greg Chandler ---
Well, it was a no-go, so I rebuilt again with --enable-checking=all
root@bigbang:/tmp# cat /tmp/1.c
#include
#include
int main ()
{
}
root@bigbang:/tmp# gcc /tmp/1.c -wrapper gdb
GN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #22 from Greg Chandler ---
Well, I guess the next thing I needed to do was chug my morning cup of cherry
coke to wake up... Since I was too tired to catch it last night, and clearly
not paying attention this morning. The linker err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #21 from Greg Chandler ---
As I typed out that last message, it dawned on me that libssp is the likely
cause of the stack protection stuff... (sigh)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #20 from Greg Chandler ---
After a marathon of table-flipping and much ado, I was able to get all the
dependcies I needed for gdb to work. So that was the good news..
The bad news is that with gdb I am still staring at this process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #19 from Greg Chandler ---
Mostly because I was in the mode of, well let me fix this one thing first, then
one after another for that. It likely would have saved me a ton of time if I
had just removed it in the first place.
I woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #17 from Greg Chandler ---
So it turns out the libiberty code in gdb is identical to gcc, so the configure
patch was needed there as well, and did not have to be modified.
I did however have to modify 10 more configure scripts to st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #16 from Greg Chandler ---
It's entirely possible I spent days chasing down the wrong thing, but I wanted
to make sure I'm not missing something much farther up stream... I don't think
the configure stuff is a distro patch problem,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #14 from Greg Chandler ---
Created attachment 61591
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61591&action=edit
This patch is likely to be superceeded by another, but fixes grep for errors
when warnings are transposed to e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #13 from Greg Chandler ---
Created attachment 61590
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61590&action=edit
Ignores warnings that are routed to stderr, causing normal checks to fail
This removes any false positives du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #12 from Greg Chandler ---
Well Patching a couple of the configure scripts fixed a long standing issue
of needing to patch code to find the headers and yeilds a clean compile.
However, the resultant native, on the native platfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #11 from Greg Chandler ---
Actually as I pointed out in a prior update, it works fine as a native...
So the cross is the one that complains about the missing main..
I'm still not sure if that is a bug, or something that is supposed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #10 from Greg Chandler ---
Ok, I was wrong, it wasn't the defines
/tmp/gcc-14.2.0/gcc.build.lnx/libiberty# cat 1.c
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #9 from Greg Chandler ---
I've done a lot of digging through the config script and am seeing some absurd
behaviour... The first of the "not detected" files is sys/file.h, and the
conftest.c created for that is this:
/tmp/gcc-14.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #8 from Greg Chandler ---
I've been digging deeper on this, and am starting to wonder if there is
something else going on behind the scenes in the build.
For example:
# grep limits.h /tmp/log-alpha
checking for limits.h... no
chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #7 from Greg Chandler ---
Iterestingly the -plugin in the stack trace shouldn't be there
So trying the no-lto example, the trace behaves the same up to that point, then
switches to this:
access("/usr/lib/gcc/alpha-linux-gnu/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #6 from Greg Chandler ---
I need to pour over this a bit too, but here is the stack trace for gcc:
fstat64(3, {st_mode=S_IFREG|0644, st_size=15611, ...}) = 0
mmap(NULL, 15611, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2034000
close(3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #5 from Greg Chandler ---
I've also confirmed that this extends to the g++ binary as well and not just
gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #4 from Greg Chandler ---
I'm not sure if the -plugin error was a red-herring, I just tried this:
root@bigbang:/tmp# gcc -fno-lto 1.c
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 68
Assignee: unassigned at gcc dot gnu.org
Reporter: chandleg at wizardsworks dot org
Target Milestone: ---
Sorry about the length of this post, it's a whopper
In 30 years have never seen this, and I'm not 100% sure where where to start to
look into it.
I buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
Greg Chandler changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
--- Comment #5 from Greg Chandler ---
Well, you definitely caught that one with the boostrap being added to configure
when it wasn't supposed to. (staring at it too long to see it)
So this isn't a bug afterall, just a mistake on configure on my
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: chandleg at wizardsworks dot org
Target Milestone: ---
lto-plugin configure fails on cross compiler build, due it trying to run a
non-platform xgcc to test. The configure script KNOWS it's a cross compile and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
--- Comment #2 from Greg Chandler ---
(squint) A 2nd pair of eyes always helps...
Let me go and remove that really quickly..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119648
--- Comment #1 from Greg Chandler ---
[ALL ]libtool: compile:
/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/./gcc/xg++
-B/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/./gcc/
-nostdinc++ -nostdi
: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: chandleg at wizardsworks dot org
Target Milestone: ---
[INFO ] Installing core C gcc compiler: done in 112.67s (at 08:25)
[INFO ] =
[INFO ] Installing C
--- Comment #6 from chandleg at wizardsworks dot org 2007-08-11 20:37
---
I have the same problem as listed here, building a x86_64 cross compiler using
32bit gcc-4.1.2
bash-3.1$ gcc -v
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.1.2/specs
Target: i486-slackware-linux
39 matches
Mail list logo
