Bug 181997 - Review Request: gpc - The GNU Pascal compiler
Review Request: gpc - The GNU Pascal compiler
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ignacio Vazquez-Abrams
Fedora Package Reviews List
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2006-02-18 12:42 EST by Jason Tibbitts
Modified: 2009-08-03 18:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-03 18:00:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to resolve the BLOCKERS (4.81 KB, patch)
2006-02-20 08:08 EST, Ralf Corsepius
no flags Details | Diff
Patch for spec file (1.06 KB, patch)
2007-06-22 17:58 EDT, Ignacio Vazquez-Abrams
no flags Details | Diff
build log from mock (2.74 KB, text/plain)
2009-02-17 00:53 EST, Caius Chance
no flags Details
Updated Patch0 that completes a build on F-10 (2.54 KB, application/octet-stream)
2009-05-19 04:57 EDT, Stijn Hoop
no flags Details

  None (edit)
Description Jason Tibbitts 2006-02-18 12:42:32 EST
Spec Name or Url: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc.spec
SRPM Name or Url: http://www.math.uh.edu/~tibbs/rpms/gpc/gpc-3.4.5_20060215-3.src.rpm
Description:
The GNU Pascal Compiler (GPC) is, as the name says, the Pascal
compiler of the GNU family (http://www.gnu.org/software/gcc/).  It:

    * can act as a native or as a cross compiler between all supported
      systems,
    * produces highly optimized code for all these systems,
    * is Free Software (Open-Source Software) according to the GNU
      General Public License,
    * is compatible to other GNU languages and tools such as GNU C and
      the GNU debugger.

The compiler supports the following language standards and quasi-standards:

    * ISO 7185 Pascal (see Resources),
    * most of ISO 10206 Extended Pascal,
    * Borland Pascal 7.0,
    * parts of Borland Delphi, Mac Pascal and Pascal-SC (PXSC).

Comments:
This is a nontrivial package, complicated by the facts that I'm no GCC expert and I haven't programmed in Pascal for a couple of decades.  One of my users requires it, so....

GPC is built against a release of GCC, but will not build against GCC 4.x.  If built against the same release of GCC as is installed on the system, the package must take care to avoid conflicts.  The normal %configure process doesn't work, and the package will not build with _smp_mflags.  Once the package is installed, most of the files must be deleted because it is not possible to just install the Pascal compiler without installing the GCC it is built against.

This has been built and tested on i386 and x86_64.  Here is the rpmlint output (on i386):

E: gpc devel-dependency gmp-devel
W: gpc unstripped-binary-or-object /usr/bin/gpidump
W: gpc unstripped-binary-or-object /usr/bin/gpc
W: gpc unstripped-binary-or-object /usr/bin/binobj
W: gpc unstripped-binary-or-object /usr/libexec/gcc/i386-redhat-linux/3.4.5/gpc1
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

Since this is a compiler, it's allowed to include devel files and dependencies in the base package.

I don't know what is wrong with /usr/libexec but several packages put things there.  Older gpc/gcc releases didn't put gpc1 under libexec, but recently they've started doing so.

I don't know about the non-utf8-ness of the info files, nor do I understand why rpmbuild did not strip the binaries.

I welcome any assistance in getting this package into shape.
Comment 1 Jochen Schmitt 2006-02-19 15:26:02 EST
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.
Comment 2 Jason Tibbitts 2006-02-19 16:14:29 EST
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.
Comment 3 Ralf Corsepius 2006-02-19 23:14:28 EST
(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.

Comment 4 Ralf Corsepius 2006-02-19 23:15:40 EST
(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."
Comment 5 Ralf Corsepius 2006-02-20 00:14:49 EST
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.]



Comment 6 Ralf Corsepius 2006-02-20 00:34:10 EST
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)
Comment 7 Ralf Corsepius 2006-02-20 08:08:03 EST
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.
Comment 8 Jason Tibbitts 2006-02-20 09:46:41 EST
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.
Comment 9 Ralf Corsepius 2006-02-20 09:56:05 EST
(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.


Comment 10 Jason Tibbitts 2006-02-20 10:05:41 EST
> 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.
Comment 11 Ralf Corsepius 2006-02-20 11:13:16 EST
(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.

Comment 12 Jason Tibbitts 2006-02-20 11:56:40 EST
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.
Comment 13 Ville Skyttä 2006-02-20 12:24:22 EST
(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.
Comment 14 Jason Tibbitts 2006-02-20 14:51:27 EST
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.
Comment 15 Jason Tibbitts 2006-02-21 12:33:49 EST
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
Comment 16 Kevin Fenzi 2006-08-14 22:36:02 EDT
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? 
Comment 17 Jason Tibbitts 2006-08-14 23:32:25 EDT
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.
Comment 18 Dominik 'Rathann' Mierzejewski 2006-11-18 20:39:14 EST
I see there anything preventing this from being reviewed? If not, I'll take it
up soon.
Comment 19 Jason Tibbitts 2006-11-18 21:02:28 EST
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.
Comment 21 Gérard Milmeister 2007-02-20 12:47:52 EST
Is gpc still developed or even maintained?
Comment 22 Jason Tibbitts 2007-02-20 12:53:22 EST
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.
Comment 23 Jason Tibbitts 2007-06-03 00:25:35 EDT
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
Comment 24 Ignacio Vazquez-Abrams 2007-06-22 17:58:55 EDT
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...
Comment 25 Matthias Saou 2007-09-01 11:34:42 EDT
Changing from NEW to ASSIGNED since Ignacio started the review.
Comment 26 Jason Tibbitts 2007-09-05 11:20:33 EDT
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
Comment 27 Jason Tibbitts 2007-09-05 21:50:21 EDT
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
Comment 28 Caius Chance 2009-02-17 00:53:19 EST
Created attachment 332178 [details]
build log from mock

patch file apply error
Comment 29 Stijn Hoop 2009-05-19 04:56:13 EDT
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.
Comment 30 Stijn Hoop 2009-05-19 04:57:01 EDT
Created attachment 344592 [details]
Updated Patch0 that completes a build on F-10
Comment 31 Jason Tibbitts 2009-08-03 18:00:36 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.