Bug 181997

Question: do gpc-debuginfo contains any files?

If not, what I assume, you have a problem with you build. During your build, the
executables should contrains debuging information. This informationen bill be
put into the gpc-debuginfo package.

Well, I just did a build in mock (development branch, i386) and it did create a
debuginfo rpm and rpmlint is quieter:

E: gpc devel-dependency gmp-devel
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtx.c
W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/libgcc.a
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/libgcc_eh.a
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/intlc.c
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/regexc.c
W: gpc devel-file-in-non-devel-package /usr/lib/gcc/i386-redhat-linux/3.4.5/libgpc.a
W: gpc file-not-utf8 /usr/share/info/gpcs-de.info.gz
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtdjgpp.h
W: gpc file-not-utf8 /usr/share/info/gpc.info.gz
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtc.h
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtlinux386.h
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtc.c
W: gpc file-not-utf8 /usr/share/info/gpcs-es.info.gz
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/pipesc.c
W: gpc file-not-utf8 /usr/share/info/gpcs-hr.info.gz
W: gpc devel-file-in-non-devel-package
/usr/lib/gcc/i386-redhat-linux/3.4.5/units/trapc.c
W: gpc non-standard-dir-in-usr libexec

I'm not sure what part of my regular build environment is different from what
mock sets up, but in any case I guess this isn't a problem with the package.

(In reply to comment #2)
> Well, I just did a build in mock (development branch, i386) and it did create a
> debuginfo rpm and rpmlint is quieter:
> 
> E: gpc devel-dependency gmp-devel
> W: gpc devel-file-in-non-devel-package
> /usr/lib/gcc/i386-redhat-linux/3.4.5/units/crtx.c
BLOCKER: /usr/lib/gcc is reserved to GCC
You must not install into it unless GCC is plugin/add-on to GCC. AFAIK, gpc is a
fork of GCC, therefore it must not install to this directory.

(In reply to comment #3)

> You must not install into it unless GCC is plugin/add-on to GCC.
This should have read ".. unless gpc is a plugin/add-on to GCC."

BLOCKER: package doesn't acknowledge RPM_OPT_FLAGS.

In FSF's GCC, this is caused by older GCC's having problems in passing down
CFLAGS (rsp. CFLAGS_FOR_HOST etc.) to it's sub-configure scripts. 

The recommended work-around in FSF-GCC is to override "CC" when invoking
configure, i.e. to
CC="%{__cc} ${RPM_OPT_FLAGS}" ./configure

I'd assume a similar step is necessary to make gpc RPM_OPT_FLAGS-aware.

[Beware: FORTIFY is known to detect memory leaks in some versions of GCC.
Depending on how clean gpc is, it therefore might be necessary to filter FORTIFY
from the CFLAGS being passed to GCC's configure.]

BLOCKER: Package doesn't build

# rpmbuild -ba gpc.spec
...
+ rm share/info/dir
rm: cannot remove `share/info/dir': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.81410 (%install)

Created attachment 124882 [details]
Patch to resolve the BLOCKERS

I am proposing the patch from the attachment. It is supposed to resolve all 3
issues I mentioned as BLOCKERS in previous comments.

Thanks for the patch.  I am curious, though: why does share/info/dir not exist
for you?  The package built everywhere I could test it, including mock on FC3,
FC4 and development i386 and x86_64.  I didn't use "rm -f" in order to find
these kinds of failures.

I don't really agree that this should live outside of /usr/lib/gcc, but it's not
exactly a big deal.  I will apply the path and force a new set of builds (which
will take a while) and present a respun package if everything goes OK.

(In reply to comment #8)
> Thanks for the patch.  I am curious, though: why does share/info/dir not exist
> for you?
I don't know, nor did I check. I just rebuilt your src.rpm under my normal build
user account (not in mock), which had tripped over this error.

> I don't really agree that this should live outside of /usr/lib/gcc, but it's
> not exactly a big deal.
Your /usr/lib/gcc files would conflict with a native gcc-3.4.5.

> Your /usr/lib/gcc files would conflict with a native gcc-3.4.5.

That's what the whole %{matching_gcc} bit in the spec is about.  On FC2 and FC3
I can actually build this package against the same version of GCC that is
installed on the system; the package then consists just of the front end and
documentation.   There is no conflict against the installed GCC.  Unfortunately
GPC has yet to be ported to GCC4, so there's no chance of doing that on FC4.

In any case, it doesn't bother me to change it, but I did go to some effort to
ensure that there is no conflict with a native gcc.

(In reply to comment #10)
> > Your /usr/lib/gcc files would conflict with a native gcc-3.4.5.
> 
> That's what the whole %{matching_gcc} bit in the spec is about.  
Well, that's how you adapt gpc to gcc, but you can't control the opposite
direction. E.g. FE or FC adding a gcc-3.4.5 to FC4 after gpc had been introduced
to FE would raise conflicts.

I applied the patch, fixed some breakage it caused switched $RPM_OPT_FLAGS to
%{optflags}, and tested builds in mock (development, i386 and x86_64).  rpmlint
output is unchanged.

New spec: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec
New SRPM: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-3.4.5_20060215-4.src.rpm

By the way, could you point me to the proper point in the packaging guidelines
where I could find the RPM_OPT_FLAGS requirement?  I can't seem to find it.

(In reply to comment #8)
> why does share/info/dir not exist for you?

The creation of that file during "make install" in most cases depends on whether
install-info is available in $PATH or not.  It may or may not be installed
depending on the dep chain, and it's not in the default $PATH of regular users
even if installed; it's in /sbin.

OK, something has broken; I thought it had built x86_64 but it didn't.  The
build fails here:

/builddir/build/BUILD/gpc-3.4.5_20060215/gcc-3.4.5/gcc/xgcc
-B/builddir/build/BUILD/gpc-3.4.5_20060215/gcc-3.4.5/
gcc/ -B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem
/usr/x86_64-redhat-linux/include -i
system /usr/x86_64-redhat-linux/sys-include -O2  -DIN_GCC    -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissi
ng-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT
_NOT_NEEDED  -I. -I. -I. -I./. -I./../include   -m32 -DL_muldi3 -c ./libgcc2.c
-o libgcc/32/_muldi3.o
In file included from /usr/include/features.h:352,
                 from /usr/include/stdio.h:28,
                 from ./tsystem.h:79,
                 from ./libgcc2.c:41:
/usr/include/gnu/stubs.h:7:27: gnu/stubs-32.h: No such file or directory

Now, /usr/include/gnu/stubs-32.h is part of glibc-devel.i386.  I have
glibc-devel as a buildreq and I swear that at one point the x86_64 mock was
pulling in both arches but how it doesn't seem to be.

So: this package requires glibc-devel.i386 to be installed in order to build on
x86_64.  How do I indicate that in the spec?  I suppose I could require
/usr/include/gnu/stubs-32.h, but that turns my stomach somewhat.

OK, I've fixed the x86_64 build by disabling multilib.  Builds succeed in mock
(development, x86_64 and i386).  rpmlint output is unchanged.  Updated files:

spec: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec
srpm: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-3.4.5_20060215-5.src.rpm

Would this package be helped any by the recent addition of the compat-gcc-34 
package to core? (it's 3.4.6, not 3.4.5 however). 

Ie, could this be reconfigured to just build the frontends and require compat-
gcc-34? 

It's possible.  Frankly I was hoping that their GCC4 work would happen sooner
rather than later, but they're still working out 4.0 compatibility while the
world is moving on to 4.1 and beyond.

The spec actually has the ability to build minimally if the installed GCC
version matches the base GCC that GPC is being patched into.  (Actually that's
pretty much required to avoid file conflicts.)  The only real issue with that is
all of the patching that Red Hat generally does to GCC.  In the past I haven't
had problems with this, however.

I see there anything preventing this from being reviewed? If not, I'll take it
up soon.

This is ticket is old enough (before FC5 was out) that sizeable bits of it need
to redone for current releases.  Unfortunately gpc doesn't patch into gcc 4.1 so
I'll have to bundle an older gcc release.

Is gpc still developed or even maintained?

It is most definitely still developed.  There is, in fact, gcc 4.1.1 support
there now, which I need to look into.

It's pretty much always going lag gcc development as long as it's not part of
the mainstream compiler source, but it's not difficult to build it as a separate
compiler that's not linked to the system's gcc version.  The spec already
handles this.

And, amazingly enough, here's an update.  The latest available patches get
things building against 4.1.2.

rpmlint has grown some new warnings in the sixteen months since I originally
submitted this package; I've solved most of them and what's left are the following:

W: gpc mixed-use-of-spaces-and-tabs (spaces: line 40, tab: line 16)
  I suppose I could stop using tabs for indentation.  I'd do that now but it 
  takes me an hour to build this so I'll get it on the next iteration.

W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/crtc.c
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/crtlinux386.h
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/trapc.c
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/libgpc.a
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/crtx.c
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/regexc.c
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/pipesc.c
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/crtc.h
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/intlc.c
W: gpc devel-file-in-non-devel-package
/usr/lib64/gpc/x86_64-redhat-linux/4.1.2/units/crtdjgpp.h
   This is a compiler, so it's going to end up with various development bits.

E: gpc devel-dependency gmp-devel
   It is not possible to build with one of the units unless gmp-devel is 
   available, and the failure is not terribly elegant.  Still, it's not a hard 
   requirement and I suppose could be removed without overt breakage, but I 
   don't see an issue with a compiler having a -devel dependency.  gcc has a 
   dependency on glibc-devel, after all.

spec: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec
SRPM: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-4.1.2_20060325-1.fc7.src.rpm

Created attachment 157661 [details]
Patch for spec file

The attached patch fixes a few cosmetic issues with the spec file. Will
continue to test the package some more...

Changing from NEW to ASSIGNED since Ignacio started the review.

A new snapshot came out yesterday; I've updated the packages.  I also did the
cleanups you suggested except for adding 
  # The compiler chokes on "-mtune=generic" further on.
which I'm afraid I don't understand; the compiler doesn't choke on any platform
I have access to.

Remaining issues that I know of:

The compiler builds two pascal executables, gpidump and binobj, which really
tick off find-debuginfo and cause it to fail the build.  I have removed these
from the package but they are mentioned in the documentation and so it would be
nice to package them.  I'm concerned that since this is built from pristine gcc
sources, it will need additional Fedora patches applied to generate build IDs.

A koji scratch build succeeds on all supported platforms, but the ppc compiler
is nonfunctional.  The ppc64 compiler is fine.  I am completely baffled.

New spec: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec
New srpm: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-4.1.2_20070904-1.src.rpm

OK, here's an update which solves the build ID issue by including a patch from
Fedora's gcc which tells the front ends to pass --build-id to the linker by default.

Also, I removed the build dependency on texinfo, as this simply regenerates the
info files and brings back all of the file-not-utf8 complaints from rpmlint.

So the only remaining issue is PPC.  I did some more poking and I understand why
the compiler fails to build things (it neglects to pick up the proper paths for
crtbegin.o and libgcc.a in the arguments passed to the linker) but I still don't
understand why this works on even PPC64 yet fails on PPC32.  I have one more
idea to try, however.

I also want to see if Jakub will have a quick look over this package.  I know he
doesn't want to incorporate GPC into the main GCC package, and I think that
would be a bad idea as long as GPC development continues to lag GCC development.
 But the "build gcc&gpc and then delete the gcc bits" approach seems to be the
only alternative, even though it's not very pretty.

New spec: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec
New srpm: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-4.1.2_20070904-2.src.rpm

Created attachment 332178 [details]
build log from mock

patch file apply error

I just ran into the patch file apply error as well, apparently the patch from Fedora 10 / 11 is more picky about the contents of the patch because this spec file used to build on Fedora 8.

Simply rediffing the ia64 part of the patch is enough to complete the build. I'll attach the patch file I used to build gpc for Fedora 10.

Created attachment 344592 [details]
Updated Patch0 that completes a build on F-10

I'm going to go ahead and close this out.  I no longer have any need for this package and haven't the will to actually get it to work properly outside of the limited use case I originally had.  The links should work for some time in case anyone decides they'd like to take my spec and improve it.