This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: crosstool-ng + arm; Build error: libc_pic.a not found


Thomas, All,

On Tuesday 22 February 2011 21:04:08 Thomas Spurden wrote:
> On 21/02/11 23:27, Yann E. MORIN wrote:
> > On Tuesday 22 February 2011 00:12:16 Thomas Spurden wrote:
> >> I'm attempting to build a toolchain for an omap3
> >> (OpenPandora/BeagleBoard), which has a cortex-a8 processor.  I'm using
> >> crosstool-ng-1.10.0 on a x86_64 host running Gentoo; gcc 4.4.4-r2,
> >> binutils 2.20.1-r1.  After a small amount of fiddling I have been
> >> stumped by the failure of the "Installing C Library" stage:
[--SNIP--]
> > You set not to build shared libraries on the target:
> >   # CT_SHARED_LIBS is not set
> > I am not really sure that glibc/eglibc can be built statically.
> > Are you _sure_ you do not want shared libraries on your target?
> I'm trying to avoid dynamic linking on the target, so just selected that
> option without thinking

There is no safe-guard in the config to avoid this configuration.
I'll see what can be done...

But anyway, if you want to avoid shared libs on the target, you can still
achieve that by statically linking your programs. Normally, both the static
and shared versions of glibc are installed. If you are really paranoid ;-)
just run something like:
  find blabla/toolchain_dir/ -type f -name '*.so' -exec rm {} \;

I know it is a shame that the toolchain can not be "by default" built with
only the static versions, but I guess the glibc build system is screwed if
it does not build/install the shared versions.

> - with it turned on the build runs through until 
> the next step (building the final compiler), and fails demanding that
> the host supports -fPIC -shared -rdynamic for plugin support.  I solved
> this by turning off the option to build a static toolchain, I guess GCC
> plugins are not supported with a static toolchain?

I guess not, although nothing should prevent it. Plugins are loaded at
runtime by means of dlopen/dlsym, and this does not require that the
executable be itself a dynamically-linked binary.

Again, the configuration should hide this combo if it is indeed not safe.
Thanks for the report. :-)

> As an aside should I be cc-ing the list?

Yes, definitely. If you come up with an answer such as "it did work!" or
"it still fails, but I tried this and that", then it will end up in the
archives, and can be searched for later in case someone encounters a
similar issue again.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]