Bug 502024 (xsd)

! About Licensing:

- While most files in the source archives are under
  GPLv2+ with exceptions which contains the clause to
  allow the linkage against xerces-c which are under ASL 2.0,
  some files are strict GPLv2.

  Then with "verbose=yes", build.log shows (for example):
-------------------------------------------------------------------------
    96  g++  -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/i386/i486/i586/i686 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/i386/i486/i586 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/i386/i486 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/i386 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/generic -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2  -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/../install/include    -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/arguments.o -c /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/arguments.cxx
   102  ar -rc /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/libcult.a /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/eh/exception.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/mm/new.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/mm/counter.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/mm/buffer.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/rtti/type-info.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/trace/log.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/arguments.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/file-arguments.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/scanner.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/options.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/options-parser.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/options-spec.o
   306  g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables     -o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/xsd /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/xsd.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/elements.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/elements.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/validator.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/name-processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/type-processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/state-processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/generator.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/parser-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/parser-inline.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/parser-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/parser-forward.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/impl-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/impl-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/driver-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/element-validation-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/attribute-validation-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/characters-validation-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/elements.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/validator.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/counter.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/name-processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/generator.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/tree-forward.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/tree-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/tree-inline.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/tree-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/parser-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/parser-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/serialization-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/serialization-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-insertion-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-insertion-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-extraction-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/type-map/lexer.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/type-map/parser.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/processing/cardinality/processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/processing/inheritance/processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/../install/lib/libxsd-frontend.a /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/../install/lib/libcult.a /usr/lib/libboost_filesystem.so /usr/lib/libboost_regex.so /usr/lib/libxerces-c.so 
-------------------------------------------------------------------------
  Here
  - libcult-1.4.2/cult/cli/arguments.cxx is under GPLv2
  - Building xsd binary uses both 
    * libcult.a (which contains libcult-1.4.2/cult/cli/arguments.o),
      which is under GPLv2
    * and libxerces-c.so which is under ASL 2.0
  They are incompatible according to
  https://fedoraproject.org/wiki/Licensing

  I guess the possible way to resolve this license conflict is to
  relicense all files in this source tarball which are under GPLv2
  to GPLv2+ (or GPLv2+ with exceptions: note that ASL 2.0 is compatible
  with GPLv3)

Setting FE-Legal.

> I guess the possible way to resolve this license conflict is to
> relicense all files in this source tarball which are under GPLv2
> to GPLv2+ (or GPLv2+ with exceptions: note that ASL 2.0 is compatible
> with GPLv3).

Either option would be acceptable, please reach out to upstream and have them correct it one way or the other.

Please let us know it when you receive some response from
the upsteam.

I sent upstream an e-mail today and will post the results here as soon as I get them. If they can not resolve the issue, I will remove the xsd compiler binary from the package until the issue is resolved (the headers are still useful for building applications that come with pre-generated binding code).

I received the following reply from Boris Kolpackov

======================================================
Thanks for your effort in packaging XSD for Fedora, it is very much
appreciated. Regarding the licensing issue, unfortunately relicensing
the code under "GPLv2 or later" is not an option at the moment and
making it "GPLv2 with exceptions" opens up a potential maintenance
problem. Let me explain: the files that are under GPLv2 are from the
base libraries that provide functionality that is not related to (nor
is aware of) Xerces-C++. In other words, code from, say libcult, is
used to parse command line arguments and just happens to be in the
same executable (xsdcxx) as code that uses Xerces-C++. Since this
GPLv2 code is not interacting in any way with the Xerces-C++ code
under ASL 2.0, my understanding of the licenses suggests that there
is no issue in having these two pieces of code in the same executable.

The problem with making this code "GPLv2 with exceptions for ASL 2.0"
is that tomorrow somebody else may start using libcult in their
program that uses another, incompatible with GPL, library. They
could then rightfully expect that we will add another exception
to the licensing condition. I think you see how this can quickly
get out of control.

Let me know if the above reasoning (the fact that the GPLv2 and ASL
code are completely independent) is acceptable to the reviewers. If
not then we will have to figure out another way.
======================================================

Well, his logic seems to be that since the libcult does not use xerces functionality, the licencse incompatibility between the two is not an issue. I'm not much of an expert on such border line licensing issues, but the logic here does seem to be similar to making a distribution: you can put different parts of the system in the same bag and distribute them together (as long as such distribution is permitted) even if the individual licenses conflict with each other. The xsd compiler binary is present in debian which has very strict licensing policies, but I don't know if debian maintainers have investigated the libcult vs xerces licensing issue.

(In reply to comment #5)
> I received the following reply from Boris Kolpackov
> 
> ======================================================
> Thanks for your effort in packaging XSD for Fedora, it is very much
> appreciated. Regarding the licensing issue, unfortunately relicensing
> the code under "GPLv2 or later" is not an option at the moment and
> making it "GPLv2 with exceptions" opens up a potential maintenance
> problem. Let me explain: the files that are under GPLv2 are from the
> base libraries that provide functionality that is not related to (nor
> is aware of) Xerces-C++. In other words, code from, say libcult, is
> used to parse command line arguments and just happens to be in the
> same executable (xsdcxx) as code that uses Xerces-C++. Since this
> GPLv2 code is not interacting in any way with the Xerces-C++ code
> under ASL 2.0, my understanding of the licenses suggests that there
> is no issue in having these two pieces of code in the same executable.

NO.
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
i.e. "Having these two pieces of code in the same executable" makes
      these all parts one big program and in this case all these codes
      must be GPLv2+ compatible.

Here is a quote from the FSF page mentioned above:

"Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)."

My point is that there is no communications between GPL and ASL licensed modules. But then the next paragraph states:

"If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program."

So things are quite murky here and, I agree, it will be more straightforward to add an explicit allowance in the licensing conditions. However, instead of adding a provision just for Xerces-C++ or ASL, I will add a general provision that will allow combining the software in question with other incompatibly-licensed modules in a single program provided that there is no use of the functionality offered by the software by such modules. Here is the text that I will place into the LICENSE file (it is similar and is based on the wording from xsd):

-------------------------------------------------------------------
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

In addition, as a special exception, Boris Kolpackov gives permission
to combine this library with other incompatibly-licensed modules in a
single program and to distribute such a combination provided that there
is no use of the functionality implemented by this library, directly
or indirectly, by such modules. You must obey the GNU General Public
License version 2 in all respects for all of the code used other than
such modules. In particular, the resulting program must be licensed
under a license compatible with the GNU General Public License version
2. If you modify this copy of the library, you may extend this exception
to your version of the library, but you are not obligated to do so. If
you do not wish to do so, delete this exception statement from your
version.
-------------------------------------------------------------------

Let me know if you see any problems with this approach.

Well, I think changing the license to LGPLv2+ will do what
you want in more simple way.

That would definitely be simpler. However, this involves two changes that I am not prepared to make at this time. Namely, the change from GPL to LGPL and the change from the specific, known version of the license to some future version which will have terms and conditions that I have no control over. So at the moment adding the above exception seems like the simplest way forward.

spot, would you judge if the license draft on comment 7
is sane for this package?

spot, would you tell us your opinion for the comment 7?

The meat of this license looks fine, but Red Hat Legal pointed out that the copyright holder in xsd appears to be both Boris Kolpackov and Code Synthesis Tools. Therefore, please change the text that says "... Boris Kolpackov gives
permission ..." to something like " ... Boris Kolpackov and Code Synthesis
Tools CC give permission ..." to make sure we're covered in case Boris's
employer is the copyright holder of some or all of the GPL-licensed
code here. 

Once this is done, we should use this for the SPEC:

# Exceptions permit otherwise GPLv2 incompatible combination with ASL 2.0
License: GPLv2 with exceptions and ASL 2.0

The xsd-3.2.0+dep package is actually the xsd compiler itself packaged with all its dependencies (there is also xsd-3.2.0 which is just the xsd compiler). Some of these dependencies are copyright Boris Kolpackov while the xsd compiler and the xsd-frontend library are copyright Code Synthesis Tools. The latter two (xsd and xsd-frontend) already include the exception that allows linking to Xerces-C++. It is the other packages (which are copyright Boris Kolpackov) that need the exception added. That's why the text uses "Boris Kolpackov" instead of "Boris Kolpackov & Code Synthesis Tools". Hope this clarifies things.

Sure, that makes sense. 

Once the package is updated with the new license, I'll lift FE-Legal.

I have released new versions of libcult, libfrontend-elements and libbackend-elements with the above license exception. I also uploaded a new version of the xsd-3.2.0+dep package which contains the new versions of the above libraries. Let me know if there is anything else you need from my side.

Updated tarball in SRPM as well as added license tag recommended in comment 12

Spec URL: http://anttix.org/fedora/pkg/xsd.spec
SRPM URL: http://anttix.org/fedora/pkg/xsd-3.2.0-2.fc10.src.rpm

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1453720

Lifting FE-Legal.

Thanx!

Can somebody now mark the package as fedora-review+ ? :)

I have a question though: does it make sense to add to spec:

Provides: xsd-devel

For example syslinux (which contains headers and closely related binaries just like this package) does so.

For 3.2.0-2:

? ace
--------------------------------------------------------
# Requires:  ace-devel - only needed for applications using ACE streams
#                             enable when Fedora gets ACE packages
--------------------------------------------------------
  - Is this differect from
    https://admin.fedoraproject.org/pkgdb/packages/name/ace ?

* compiler flags
--------------------------------------------------------
    67  make: Entering directory `/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult'
    68  m4 /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/cli/mapper.hxx.m4
    69  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/eh/exception.cxx
    70  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/mm/new.cxx
    71  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/mm/counter.cxx
    72  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/mm/buffer.cxx
    73  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/rtti/type-info.cxx
    74  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/trace/log.cxx
--------------------------------------------------------
  - From this build.log it "seems" that Fedora specific compilation
    flags are not honored correctly:
    https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags

    Please make it sure that Fedora specific compilation flags are
    correctly honored. If this is already honored, make build.log more
    verbose so that we can easily check it from build.log.

! rpmlint warnings
---------------------------------------------------------
xsd-doc.i586: W: file-not-utf8 /usr/share/doc/xsd-doc-3.2.0/cxx/tree/guide/cxx-tree-guide.ps
xsd-doc.i586: W: file-not-utf8 /usr/share/doc/xsd-doc-3.2.0/cxx/parser/guide/cxx-parser-guide.ps
xsd-doc.i586: W: file-not-utf8 /usr/share/doc/xsd-doc-3.2.0/cxx/tree/manual/cxx-tree-manual.ps
---------------------------------------------------------
  - Can these files be converted into UTF-8 easily?

(In reply to comment #18)
> I have a question though: does it make sense to add to spec:
> Provides: xsd-devel

I don't think this is needed.

(In reply to comment #19)

> ? ace
> --------------------------------------------------------
> # Requires:  ace-devel - only needed for applications using ACE streams
> #                             enable when Fedora gets ACE packages
> --------------------------------------------------------
>   - Is this differect from
>     https://admin.fedoraproject.org/pkgdb/packages/name/ace ?

Yep!
The ace that XSD supports is an Adaptive Communication Environment
and can be found from here:
http://www.cs.wustl.edu/~schmidt/ACE.html

I'll add this URL as a comment to the spec file as a reminder what the hell
is ACE ;)

>     Please make it sure that Fedora specific compilation flags are
>     correctly honored. If this is already honored, make build.log more
>     verbose so that we can easily check it from build.log.

I'll look into it. Thanx.

> ---------------------------------------------------------
> xsd-doc.i586: W: file-not-utf8
> /usr/share/doc/xsd-doc-3.2.0/cxx/tree/guide/cxx-tree-guide.ps
> xsd-doc.i586: W: file-not-utf8
> /usr/share/doc/xsd-doc-3.2.0/cxx/parser/guide/cxx-parser-guide.ps
> xsd-doc.i586: W: file-not-utf8
> /usr/share/doc/xsd-doc-3.2.0/cxx/tree/manual/cxx-tree-manual.ps
> ---------------------------------------------------------
>   - Can these files be converted into UTF-8 easily?  

Unfortunately I'm not aware of a tool that can convert Postscript files to UTF-8. I tried to do it manually, but wasn't successful :(
I did however document this error in initial report.

(In reply to comment #21)
> (In reply to comment #19)
> 
> > ? ace
> > --------------------------------------------------------
> > # Requires:  ace-devel - only needed for applications using ACE streams
> > #                             enable when Fedora gets ACE packages
> > --------------------------------------------------------
> >   - Is this differect from
> >     https://admin.fedoraproject.org/pkgdb/packages/name/ace ?
> 
> Yep!
> The ace that XSD supports is an Adaptive Communication Environment
> and can be found from here:
> http://www.cs.wustl.edu/~schmidt/ACE.html

Ah, thanks. This one is review request bug 450164 (which
is blocked by legal issue)

(In reply to comment #19)

>     correctly honored. If this is already honored, make build.log more
>     verbose so that we can easily check it from build.log.

Build flags were already correctly honoured, the build log is now more verbose.

Updated package:
 %build
-CXXFLAGS=$RPM_OPT_FLAGS ./build.sh
+MAKEFLAGS="verbose=1" CXXFLAGS=$RPM_OPT_FLAGS ./build.sh

Also added new entries to changelog and a few comments.

Spec URL: http://anttix.org/fedora/pkg/xsd.spec
SRPM URL: http://anttix.org/fedora/pkg/xsd-3.2.0-3.fc10.src.rpm

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1457171

Okay.

----------------------------------------------------------------
    This package (xsd) is APPROVED by mtasaka
----------------------------------------------------------------

Thank You!

New Package CVS Request
=======================
Package Name: xsd
Short Description: W3C XML schema to C++ data binding compiler
Owners: anttix
Branches: F-10 F-11 EL-5
InitialCC:

> Requires:  ace-devel

I don't think adding a requirement for ACE is a good idea. ACE support is optional and I would expect only a few people needing this functionality (binary serialization to ACE CDR streams). Is there something like Suggests: or Recommends: ?

> Can these files be converted into UTF-8 easily?  

I think these files can be safely removed from the package. They are a by-product of creating the PDF files from XHTML and we only keep them because, well, we have them and maybe somebody would need them for something.

(In reply to comment #26)

> > Requires:  ace-devel
> 
> I don't think adding a requirement for ACE is a good idea. ACE support is
> optional and I would expect only a few people needing this functionality
> (binary serialization to ACE CDR streams). Is there something like Suggests: or
> Recommends: ?  

AFAIK there is no "recommended packages" information in RPM files.
The dependency is currently commented out because Fedora does not have ACE packages. If they become available, the decision whether to depend on them or not can be made. The current information in the spec file serves only as a reminder to me and other package maintainers to look into the issue when ACE packages become available.

cvs done.

xsd-3.2.0-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/xsd-3.2.0-4.fc11

xsd-3.2.0-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/xsd-3.2.0-4.fc10

Now closing (it seems that on EL5 build fails due to gcc's ICE, however
anyway I close because on F-12/11/10 build succeeded)

Yeah! I am trying to get some meaningful debug information out of GCC to report a bug against EL-5.

The compiler bug shows up when -g switch is added to GCC command line.

So I have to ask: is it acceptable to remove -g from build flags as a temporary workaround so the package will build?

This will have the side-effect of killing xsd-debuginfo package.

EL5 has gcc43, but this one is unable to link ...

/usr/bin/ld: /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/xsd: hidden symbol `void std::__ostream_fill<char, std::char_traits<char> (std::basic_ostream<char, std::char_traits<char> >&, long)' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

The only way I can get it to build on EL5 is by filtering -g from
RPM_OPT_FLAGS :(

> The compiler bug shows up when -g switch is added to GCC command line.

Yes, this a known problem with some earlier g++ 4.x versions. It is triggered when both optimization and debug information are requested (e.g., -O2 -g). Removing -g from the compilation flags should be harmless since it only affects the XSD compiler itself (i.e., there won't be any debug information in the compiler binary). Since the runtime library is header-only, the user applications that use the generated code won't be affected.

Well, I have now managed to get the package to link with gcc43 on EL5:

 %build
+CXX=g++43 LIBS=`$CXX -print-file-name=libstdc++.a` \
 MAKEFLAGS="verbose=1" CXXFLAGS=$RPM_OPT_FLAGS ./build.sh

$CXX -print-file-name=libstdc++.a evaluates to:
/usr/lib/gcc/i386-redhat-linux6E/4.3.2/libstdc++.a
which is part of a libstdc++43-devel package.

There is no corresponding libstdc++43 package.

This makes me nervous, since I'm not sure which parts of libstdc++ are now statically linked and which are still dynamic.
According to this blog post (http://www.trilithium.com/johan/2005/06/static-libstdc/), mixing statically and dynamically linked C++ code is not a very good idea.

Which would be the proper solution for EL5?
Filter -g and stick with GCC4.1 or compile with 4.3 and hope that this strange linking method actually works?

I would suggest we filter -g out if this is acceptable. Your concern about linking to static libstdc++ is quite correct. There is another support library (libgcc_s) that is linked dynamically and the resulting executable will use the one from g++-4.1.

The RHEL 5.4 beta announcement mentions "GCC 4.4". Maybe that'll help.

The default debug information level is 2 when using -g switch. However, xsd seems to build fine with -g1, but with that we'd lose line numbers and local variable information when compared to full -g.

The following produces a -debuginfo package, but source files don't get included in it because of the -g1 switch used:

 %build
-MAKEFLAGS="verbose=1" CXXFLAGS=$RPM_OPT_FLAGS ./build.sh
+MAKEFLAGS="verbose=1" CXXFLAGS="$RPM_OPT_FLAGS -g1" ./build.sh

Would you contact gcc maintainer (i.e. file a bug report against
gcc) first?

Also for EL-5 build issue, please open a new bug ticket (against
xsd componet) and discuss there.

xsd-3.2.0-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

xsd-3.2.0-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.