You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2006/08/07 20:49:26 UTC
link failure in exec
The exec utility is failing to link with Compaq/HP C++ on Tru64
and with Sun C++ on Solaris. One of the errors is below. I marrowed
down the problem to compiler bugs (limitations) on these systems
and crated "External" issues for reference:
http://issues.apache.org/jira/browse/STDCXX-266
http://issues.apache.org/jira/browse/STDCXX-267
I suspect the vendors of the buggy compiler will not be able to fix
the bugs because of binary compatibility concerns and we will need
to work around them by being consistent about the way we declare
and define functions.
...
gmake[2]: Entering directory `/build/sebor/cxx-6.5-15s/bin'
...
cxx runall.o cmdopt.o output.o util.o exec.o -o exec -nocxxstd -liconv
-pthread -ptr repository.ti -L/build/sebor/cxx-6.5-15s/lib -lstd15s
-D_RWSTDDEBUG -pthread -D_RWSTD_USE_CONFIG
-I/amd/devco/sebor/dev/stdlib/include -I/build/sebor/cxx-6.5-15s/include
-I/amd/devco/sebor/dev/stdlib/include/loc -lm
ld:
Unresolved:
split_opt_string(const char*)
eval_options(int, char* const*)
gmake[2]: *** [exec] Error 1
gmake[2]: Leaving directory `/build/sebor/cxx-6.5-15s/bin'
gmake[1]: *** [util] Error 2
gmake[1]: Leaving directory `/build/sebor/cxx-6.5-15s'
gmake: *** [libstd] Error 2
Re: link failure in exec
Posted by Martin Sebor <se...@roguewave.com>.
Justin Erenkrantz wrote:
> On 8/7/06, Martin Sebor <se...@roguewave.com> wrote:
>
>> The exec utility is failing to link with Compaq/HP C++ on Tru64
>> and with Sun C++ on Solaris. One of the errors is below. I marrowed
>> down the problem to compiler bugs (limitations) on these systems
>> and crated "External" issues for reference:
>>
>> http://issues.apache.org/jira/browse/STDCXX-266
>> http://issues.apache.org/jira/browse/STDCXX-267
>>
>> I suspect the vendors of the buggy compiler will not be able to fix
>> the bugs because of binary compatibility concerns and we will need
>> to work around them by being consistent about the way we declare
>> and define functions.
>
>
> FYI, this occurs with the latest Sun Studio patchset too...
I don't expect them to fix it anytime soon (if ever). Most
commercial compiler vendors are extremely careful about
maintaining binary compatibility. I've fixed it with this
change: http://svn.apache.org/viewvc?rev=429481&view=rev
Martin
>
> % CC -c -V t.cpp -o foo.o && CC -DMAIN t.cpp foo.o
> CC: Sun C++ 5.8 Patch 121018-02 2006/04/26
> ccfe: Sun C++ 5.8 Patch 121018-02 2006/04/26
> Undefined first referenced
> symbol in file
> void foo(int) t.o
> ld: fatal: Symbol referencing errors. No output written to a.out
>
> HTH. -- justin
Re: link failure in exec
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/7/06, Martin Sebor <se...@roguewave.com> wrote:
> The exec utility is failing to link with Compaq/HP C++ on Tru64
> and with Sun C++ on Solaris. One of the errors is below. I marrowed
> down the problem to compiler bugs (limitations) on these systems
> and crated "External" issues for reference:
>
> http://issues.apache.org/jira/browse/STDCXX-266
> http://issues.apache.org/jira/browse/STDCXX-267
>
> I suspect the vendors of the buggy compiler will not be able to fix
> the bugs because of binary compatibility concerns and we will need
> to work around them by being consistent about the way we declare
> and define functions.
FYI, this occurs with the latest Sun Studio patchset too...
% CC -c -V t.cpp -o foo.o && CC -DMAIN t.cpp foo.o
CC: Sun C++ 5.8 Patch 121018-02 2006/04/26
ccfe: Sun C++ 5.8 Patch 121018-02 2006/04/26
Undefined first referenced
symbol in file
void foo(int) t.o
ld: fatal: Symbol referencing errors. No output written to a.out
HTH. -- justin