stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (STDCXX-116) [Mac OS X 10.2.8] Examples fail to build due to LD error
Date Tue, 29 May 2007 23:18:15 GMT

     [ https://issues.apache.org/jira/browse/STDCXX-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Martin Sebor reassigned STDCXX-116:
-----------------------------------

    Assignee: Andrew Black

Andrew, is this something that we still need to worry about given what Brad said in STDCXX-358?
(I.e., that once it's resolved along with issue 357, STDCXX builds and runs fine on Mac OS
X.) Or is this an outdated version of the OS and/or compiler? If the latter, please close
the issue.

> [Mac OS X 10.2.8] Examples fail to build due to LD error
> --------------------------------------------------------
>
>                 Key: STDCXX-116
>                 URL: https://issues.apache.org/jira/browse/STDCXX-116
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: Build
>         Environment: Mac OS X 10.2.8/Darwin 6.8 with GCC 3.1
>            Reporter: Andrew Black
>            Assignee: Andrew Black
>
> When attempting to build the examples as part of the make sequence, I recieve the following
messages
> gcc -c -I/Volumes/Orion/Work/stdcxx/include/ansi   -D_RWSTD_USE_CONFIG -I/Users/blackaw/Documents/Work/stdcxx//include
-I/Volumes/Orion/Work/stdcxx/include -I/Volumes/Orion/Work/stdcxx/examples/include  -pedantic
-nostdinc++  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
 /Volumes/Orion/Work/stdcxx/examples/manual/accum.cpp
> gcc accum.o -o accum  -L/Users/blackaw/Documents/Work/stdcxx//lib -lstd  -lsupc++ -lm
> ld: archive: /Users/blackaw/Documents/Work/stdcxx//lib/libstd.a has no table of contents,
add one with ranlib(1) (can't load from it)
> make[2]: *** [accum] Error 1
> make[1]: [examples] Error 2 (ignored)
> The obvious solution is to call ranlib as part of the make process for the library, but
this would involve altering the make proccess for the config tests, library and test library,
along with requiring conditional logic to protect other platforms/compilers from this step
that would likely cause problems.
> Looking at the man page for ranlib on my linux box here, it appears that a better solution
could be to define ARFLAGS for gcc as being '-s', though I could potentially see problems
emerging were this to be an unconditional definition.
> I will try this solution tonight.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message