You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Keith Marshall (JIRA)" <xe...@xml.apache.org> on 2015/09/14 23:45:46 UTC
[jira] [Comment Edited] (XERCESC-2048) Error during build on
Windows/MinGW because of LDFLAGS=-no-undefined
[ https://issues.apache.org/jira/browse/XERCESC-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14744294#comment-14744294 ]
Keith Marshall edited comment on XERCESC-2048 at 9/14/15 9:45 PM:
------------------------------------------------------------------
This is just so broken that it beggars belief!
I too encountered this, and my initial reaction to seeing the build instruction was to ask "why would that be required?" In the first place "\-no-undefined", (or more accurately, the linker flag "\-\-no-undefined"), is *never* required when building windows DLLs, (if specified, it is effectively a no-op), so I should just be able to ignore this bogus instruction. Not so, of course, because not only do the guys who have written this build system not understand the purpose of "\-\-no-undefined", they have actually implemented a build time test to check that this utterly useless option is specified.
Okay, so even though it does absolutely nothing useful, we must specify this nonsense just to get around this build system fault. However, if we do specify it as
./configure LDFLAGS=-no-undefined
as the build instructions dictate, the configure script must immediately blow up, because LDFLAGS are passed to gcc in the compiler identification tests, and "\-no-undefined" is *not* a valid gcc flag; (it is a linker option, correctly specified as "\-\-no-undefined", which can only be passed through gcc in the form "\-Wl,--no-undefined"). When gcc sees "\-no-undefined" it chokes, causing configure to abort with (for me) a "compiler cannot create executables" exception, (which may seem misleading, but is true when invoked with an invalid option, simply because the command line is invalid).
As a quick and dirty workaround for this bug, we may defer the "LDFLAGS=-no-undefined" specification to the make step, omitting it from the configure command:
./configure ...; # do NOT specify "LDFLAGS=-no-undefined" here!
...
make LDFLAGS=-no-undefined
However, the proper solution would be to fix the build system, such that the requirement to specify this entirely pointless linker flag is eliminated.
was (Author: kdm):
This is just so broken that it beggars belief!
I too encountered this, and my initial reaction to seeing the build instruction was to ask "why would that be required?" In the first place "-no-undefined", (or more accurately, the linker flag "--no-undefined"), is *never* required when building windows DLLs, (if specified, it is effectively a no-op), so I should just be able to ignore this bogus instruction. Not so, of course, because not only do the guys who have written this build system not understand the purpose of "--no-undefined", they have actually implemented a build time test to check that this utterly useless option is specified.
Okay, so even though it does absolutely nothing useful, we must specify this nonsense just to get around this build system fault. However, if we do specify it as
./configure LDFLAGS=-no-undefined
as the build instructions dictate, the configure script must immediately blow up, because LDFLAGS are passed to gcc in the compiler identification tests, and "-no-undefined" is *not* a valid gcc flag; (it is a linker option, correctly specified as "--no-undefined", which can only be passed through gcc in the form "-Wl,--no-undefined"). When gcc sees "-no-undefined" it chokes, causing configure to abort with (for me) a "compiler cannot create executables" exception, (which may seem misleading, but is true when invoked with an invalid option, simply because the command line is invalid).
As a quick and dirty workaround for this bug, we may defer the "LDFLAGS=-no-undefined" specification to the make step, omitting it from the configure command:
./configure ...; # do NOT specify "LDFLAGS=-no-undefined" here!
...
make LDFLAGS=-no-undefined
However, the proper solution would be to fix the build system, such that the requirement to specify this entirely pointless linker flag is eliminated.
> Error during build on Windows/MinGW because of LDFLAGS=-no-undefined
> ---------------------------------------------------------------------
>
> Key: XERCESC-2048
> URL: https://issues.apache.org/jira/browse/XERCESC-2048
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
> Affects Versions: 3.1.2
> Environment: Windows 8.1 with MinGW
> Reporter: Philip Young
> Priority: Blocker
>
> Followed the build instructions and used ./configure LDFLAGS=-no-undefined
> config.log shows the following:
> Target: mingw32
> Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
> Thread model: win32
> gcc version 4.8.1 (GCC)
> configure:3781: $? = 0
> configure:3770: g++ -V >&5
> g++.exe: error: unrecognized command line option '-V'
> g++.exe: fatal error: no input files
> compilation terminated.
> configure:3781: $? = 1
> configure:3770: g++ -qversion >&5
> g++.exe: error: unrecognized command line option '-qversion'
> g++.exe: fatal error: no input files
> compilation terminated.
> configure:3781: $? = 1
> configure:3801: checking whether the C++ compiler works
> configure:3823: g++ -no-undefined conftest.cpp >&5
> g++.exe: error: unrecognized command line option '-no-undefined'
> configure:3827: $? = 1
> configure:3865: result: no
> configure: failed program was:
> | /* confdefs.h */
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org