This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] GCC-4 new packaging.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dave Korn wrote:
>   I'm about ready to release a new compiler package.  This is going to mean a
> whole bunch of new packages and one obsoletion, and I was hoping I could get a
> hand proof-reading the setup hints and any comments anyone has on packaging,
> names and categories.

Sure...

>   First off, there's a whole bunch of new runtime libraries:
> 
> gcc4-libgcc1-runtime-4.3.2-2
> ./usr/bin/cyggcc_s-1.dll
> 
> gcc4-libgomp1-runtime-4.3.2-2
> ./usr/bin/cyggomp-1.dll
> 
> gcc4-libssp0-runtime-4.3.2-2
> ./usr/bin/cygssp-0.dll
> 
> gcc4-libgfortran3-runtime-4.3.2-2
> ./usr/bin/cyggfortran-3.dll
> 
> gcc4-libffi4-runtime-4.3.2-2
> ./usr/bin/cygffi-4.dll
> 
> gcc4-libgcj9-runtime-4.3.2-2
> ./usr/bin/cyggcj-9.dll
> ./usr/bin/cyggcj-tools-9.dll
>
> gcc4-libobjc2-runtime-4.3.2-2
> ./usr/bin/cygobjc-2.dll
>
> gcc4-libstdc++6-runtime-4.3.2-2
> ./usr/bin/cygstdc++-6.dll
>
> gcc4-libgnat4.3-runtime-4.3.2-2
> ./usr/bin/cyggnarl-4.3.dll
> ./usr/bin/cyggnat-4.3.dll

The gcc4- and -runtime are just confusing; these should be just libgcc1,
libgomp1, etc.  Remember that these will be runtime dependencies for
other packages, and these names are consistent with (most) other runtime
libraries, and match those in Debian.

> gcc4-java-runtime-config-4.3.2-2
> ./etc/defaults/usr/lib/logging.properties
> ./etc/defaults/usr/lib/security/classpath.security
> ./etc/postinstall/gcc4-java-runtime-config.sh
> ./etc/preremove/gcc4-java-runtime-config.sh

I would call this libgcj-common, as in Debian.

>   I considered breaking out the Java and GNAT DLLs into individual packages,
> but figure they're liable to be so closely coupled that it would be pointless.
>  I don't know if it's even worth having a separate package for the java config
> files, but I did it anyway.

It is worth it, because if the libgcj ABI gets bumped in a future
version of gcc, you can't have those files bundled with two versions of
libgcj, as they will collide.

>   Note also that there is no gcc4-runtime-4.3.2-2, which was the package that
> contained the old unversioned cyggcc_s.dll we've been using so far.  In order
> to obsolete it, can I just update the existing setup.hint to move it into the
> _obsolete category, or does there need to be a version number change?

Since the files don't collide (libgcc1 is now versioned), just mark it
_obsolete; no version bump is necessary.

>   Next are the main compiler packages.  I would be glad if anyone could cast
> an eye over the list of package contents for me and sanity check that I
> haven't put anything in obviously the wrong place.  Each one should contain
> just the executables, headers, link libs and docs relevant to its language.
> 
> gcc4-4.3.2-2
> ./usr/share/doc/gcc4-4.3.2
> ./usr/share/doc/Cygwin/gcc4-4.3.2.README
> ./usr/share/man/man7/fsf-funding.7.gz
> ./usr/share/man/man7/gfdl.7.gz
> ./usr/share/man/man7/gpl.7.gz
> 
> gcc4-core-4.3.2-2
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/include/*.h
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/include/ssp
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/include-fixed
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/install-tools
> ./usr/bin/cpp-4.exe
> ./usr/bin/gcc-4.exe
> ./usr/bin/gccbug-4
> ./usr/bin/gcov-4.exe
> ./usr/bin/i686-pc-cygwin-gcc-4.3.2.exe
> ./usr/bin/i686-pc-cygwin-gcc-4.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/cc1.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/collect2.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/crtbegin.o
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/crtend.o
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/crtfastmath.o
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_eh.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcov.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgomp.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgomp.dll.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgomp.la
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgomp.spec
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libssp.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libssp.dll.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libssp.la
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libssp_nonshared.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libssp_nonshared.la
> ./usr/share/locale/*
> ./usr/share/info/cpp.info.gz
> ./usr/share/info/cppinternals.info.gz
> ./usr/share/info/gcc.info.gz
> ./usr/share/info/gccinstall.info.gz
> ./usr/share/info/gccint.info.gz
> ./usr/share/info/libgomp.info.gz
> ./usr/share/man/man1/cpp-4.1.gz
> ./usr/share/man/man1/gcc-4.1.gz
> ./usr/share/man/man1/gcov-4.1.gz

What is the reason for separating gcc and gcc-core?  Yes, I know that
gcc-3.4 did this also, but I don't remember the rationale.

> gcc4-g++-4.3.2-2
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++
> ./usr/bin/c++-4.exe
> ./usr/bin/g++-4.exe
> ./usr/bin/i686-pc-cygwin-c++-4.exe
> ./usr/bin/i686-pc-cygwin-g++-4.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/cc1plus.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libsupc++.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libsupc++.la
> ./usr/share/man/man1/g++-4.1.gz

I'm tempted to suggest a libstdc++6-devel (yes, versioned, because the
includes and link libs are in versioned directories), for C++ libtool
libraries that provide a C interface (and hence may be built against
with just gcc).

> gcc4-java-4.3.2-2
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/include/gcj
> ./usr/lib/gcj-4.3.2-9
> ./usr/share/java
> ./usr/bin/addr2name.awk-4
> ./usr/bin/gappletviewer-4.exe
> ./usr/bin/gc-analyze-4.exe
> ./usr/bin/gcj-4.exe
> ./usr/bin/gcj-dbtool-4.exe
> ./usr/bin/gcjh-4.exe
> ./usr/bin/gij-4.exe
> ./usr/bin/gjar-4.exe
> ./usr/bin/gjarsigner-4.exe
> ./usr/bin/gjavah-4.exe
> ./usr/bin/gkeytool-4.exe
> ./usr/bin/gnative2ascii-4-4.exe
> ./usr/bin/gorbd-4.exe
> ./usr/bin/grmic-4.exe
> ./usr/bin/grmid-4.exe
> ./usr/bin/grmiregistry-4.exe
> ./usr/bin/gserialver-4.exe
> ./usr/bin/gtnameserv-4.exe
> ./usr/bin/i686-pc-cygwin-gcj-4.exe
> ./usr/bin/jcf-dump-4.exe
> ./usr/bin/jv-convert-4.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/jc1.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/jvgenmain.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcj-tools.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcj-tools.dll.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcj-tools.la
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcj.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcj.dll.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcj.la
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcj.spec
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgij.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgij.la
> ./usr/lib/libffi.a
> ./usr/lib/libffi.dll.a
> ./usr/lib/libffi.la
> ./usr/lib/pkgconfig/libgcj-4.3.pc
> ./usr/share/info/cp-tools.info.gz
> ./usr/share/info/gcj.info.gz
> ./usr/share/man/man1/gappletviewer-4.1.gz
> ./usr/share/man/man1/gc-analyze-4.1.gz
> ./usr/share/man/man1/gcj-4.1.gz
> ./usr/share/man/man1/gcj-dbtool-4.1.gz
> ./usr/share/man/man1/gcjh-4.1.gz
> ./usr/share/man/man1/gij-4.1.gz
> ./usr/share/man/man1/gjar-4.1.gz
> ./usr/share/man/man1/gjarsigner-4.1.gz
> ./usr/share/man/man1/gjavah-4.1.gz
> ./usr/share/man/man1/gkeytool-4.1.gz
> ./usr/share/man/man1/gnative2ascii-4.1.gz
> ./usr/share/man/man1/gorbd-4.1.gz
> ./usr/share/man/man1/grmic-4.1.gz
> ./usr/share/man/man1/grmid-4.1.gz
> ./usr/share/man/man1/grmiregistry-4.1.gz
> ./usr/share/man/man1/gserialver-4.1.gz
> ./usr/share/man/man1/gtnameserv-4.1.gz
> ./usr/share/man/man1/jcf-dump-4.1.gz
> ./usr/share/man/man1/jv-convert-4.1.gz

Please create a separate libffi-devel with ffi*.h (which I don't see
listed here) and libffi.*, as there are C packages that use libffi as well.

BTW, why is libgij static-only?

> gcc4-fortran-4.3.2-2
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/finclude
> ./usr/bin/gfortran-4.exe
> ./usr/bin/i686-pc-cygwin-gfortran-4.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/f951.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgfortran.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgfortran.dll.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgfortran.la
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgfortranbegin.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libgfortranbegin.la
> ./usr/share/info/gfortran.info.gz
> ./usr/share/man/man1/gfortran-4.1.gz
> 
> gcc4-objc-4.3.2-2
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/include/objc
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/cc1obj.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/cc1objplus.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libobjc.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libobjc.dll.a
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/libobjc.la
> 
> gcc4-ada-4.3.2-2
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/adainclude
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/adalib
> ./usr/bin/gnat-4.exe
> ./usr/bin/gnatbind-4.exe
> ./usr/bin/gnatbl-4.exe
> ./usr/bin/gnatchop-4.exe
> ./usr/bin/gnatclean-4.exe
> ./usr/bin/gnatfind-4.exe
> ./usr/bin/gnatkr-4.exe
> ./usr/bin/gnatlink-4.exe
> ./usr/bin/gnatls-4.exe
> ./usr/bin/gnatmake-4.exe
> ./usr/bin/gnatname-4.exe
> ./usr/bin/gnatprep-4.exe
> ./usr/bin/gnatxref-4.exe
> ./usr/lib/gcc/i686-pc-cygwin/4.3.2/gnat1.exe
> ./usr/share/info/gnat-style.info.gz
> ./usr/share/info/gnat_rm.info.gz
> ./usr/share/info/gnat_ugn_unw.info.gz

Otherwise looks okay; cygport will tell you if you're missing anything.

>   Lastly, I've attached my hint files, and again, I could really use a hand
> proof-reading and sanity checking, because there's so many of them I'm almost
> bound to have made a cut and paste error that I've now looked at too many
> times to be able to see.
> 
>   The things to look out for are did I get the sdesc right, is the category
> right (Devel for all, also Libs for the runtimes), and do the requires lines
> look like they're vaguely right or contain any obvious gaping omissions.

objc.hint: /^req/ s/gcc4-c++/gcc4-g++/

I know there was some discussion about deps on _update-info-dir
recently, but AFAICS it only makes sense for texinfo to depend on
_update-info-dir.  It's irrelevant if the package installs .info pages
if the user doesn't have texinfo to view them!

>   Obviously nobody can verify they're actually right without having copies of
> the DLLs themselves, but I used a script to collect the cygcheck output for
> all the DLLs and executables in the packages and generated the attached
> deps.txt file from it, so anyone who was feeling particularly keen could give
> it another cross-check for me..... pretty please? ;-)
> 
>   So, barring last minute hitches, I should be able to upload this around the
> end of the week.  I would welcome any comments or advice on the packaging,
> because this is a major transition and I'd like to get it right and not
> inconvenience any of the users.  Opinions welcome!

That's my 0.02 (CAD).


Yaakov

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkmPycEACgkQpiWmPGlmQSNrxQCdERDPIRVW82GNeU8Qx47x005q
6C4An2vgkywtbAR9mxRgiYTMnXfiVIDw
=zD29
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]