[
https://issues.apache.org/jira/browse/XERCESC-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623586#action_12623586
]
Bugger It commented on XERCESC-1069:
------------------------------------
I hit this same problem with Xerces C 2.7.0, but not with 2.8.0. I haven't
tried Xerces C 3.0.
I'm using GCC 4.2.3 on sparc-sun-solaris2.9, building an LP64 Xerces lib, and
building using:
In 2.7.0, the 'runConfigure' script attempts to guess the set of options that
should be passed to the C compiler to create LP64 executables.
It may guess correctly some of the time, but at least in my case above, it
guesses wrongly on two counts:
- It adds the unsupported option '-xarch' to GCC command lines, as well as to
Sun Studio cc command lines (where it would be supported); and
- It fails to add the required flag '-m64' when building with newer versions of
GCC that support this flag, and require it for LP64 builds.
But we mustn't pass -m64 to older GCCs, which need a different option that I
forget.
I claim this script should not guess at all. GNU autoconf exists specifically
to avoid this type of guesswork, and Xerces C 2.7.0 already uses autoconf. So
why are we guessing in shell?
As far as I can see, the most correct fix would be to remove the guesswork
about CFLAGS from 'runConfigure', and replace it with autoconf M4 macros to
programmatically discover the set of options which, when passed to whatever C
compiler(s) are in use, causes them to output working LP64 executables.
Correctness could be tested by confirming that the binary works, and that 'file
<binary>' outputs a string containing '64'. I hope that version 3.0 does
something like this.
I am sure there will be existing M4 macros to do this, but I don't see them in
the Xerces C 2.7.0 source, so I don't see an easy way for me to implement this.
So all I have done is removed all knowledge of the variable CFLAGS from the
script 'runConfigure', and am setting all the necessary values using
runConfigure's switches for this, as a previous poster is in the case of the
-m64 options. Ie, remove this broken functionality from the build scripts, and
then do it all yourself.
I cannot see any reason at all for the existence of this 'runConfigure' crock,
and several reasons for it not to exist. I hope you've deleted this
brain-damage from version 3.0.
All it does is run ./configure with some environment variables and options,
some of which are anyway incorrect.
Why does the documentation recommend to use this pointless and broken
'runConfigure' wrapper?
What is wrong with just doing ./configure ; make ; make install in the normal
way that almost every other FLOSS package uses?
Is this an attempt to improve usability for novice system administrators, at
cost of everyone else?
And why on earth do you hide the generated compiler command lines?
Is this an attempt to hide 'scary technical things' such as compiler command
lines from novice sysadmins?
What would be the point of that? How will they learn if you hide everything
from them?
It seems to me that you are trying to make the process of building your
software from source code so easy that ignorant/novice system administrators,
who should never be performing any such task in the first place, can do it. But
aren't pre-compiled binaries for exactly this type of person?
If a human cannot handle compiler command lines, (s)he probably can't handle
XML either. So (s)he has no use for your software.
If you make your build process idiot-proof, Nature will simply create a better
idiot. You can't win, and you shouldn't waste time trying.
> configure gcc 64-bit on solaris fails
> -------------------------------------
>
> Key: XERCESC-1069
> URL: https://issues.apache.org/jira/browse/XERCESC-1069
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
> Affects Versions: 2.3.0
> Environment: Operating System: Other
> Platform: Other
> Reporter: John Ky
> Assignee: Xerces-C Developers Mailing List
>
> When:
> ./runConfigure -p$OSTYPE -cgcc -xg++ -minmem -nsocket -tnative -rpthread -b 64
> The configure script fails on Solaris 9 fails because it uses the
> compiler/linker options -xarch=v9 instead of -m64 -mcpu=v9.
> gcc has no such command line options.
> It is possible to use runConfigure with the following options instead:
> ./runConfigure -p$OSTYPE -cgcc -xg++ -minmem -nsocket -tnative -rpthread -l
> "-m64" -l "-mcpu=v9" -z "-m64" -z "-mcpu=v9"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
