Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 3360874
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 18, 20262026-05-18T03:03:20+00:00 2026-05-18T03:03:20+00:00

I have a program, myprogram , which is linked with a static convenience library,

  • 0

I have a program, myprogram, which is linked with a static convenience library, call it libconvenience.a, which contains a function, func(). The function func() isn’t called anywhere in myprogram; it needs to be able to be called from a plugin library, plugin.so.

The symbol func() is not getting exported dynamically in myprogram. If I run

nm myprogram | grep func

I get nothing. However, it isn’t missing from libconvenience.a:

nm libconvenience/libconvenience.a | grep func
00000000 T func

I am using automake, but if I do the last linking step by hand on the command line instead, it doesn’t work either:

gcc -Wl,--export-dynamic -o myprogram *.o libconvenience/libconvenience.a `pkg-config --libs somelibraries`

However, if I link the program like this, skipping the use of a convenience library and linking the object files that would have gone into libconvenience.a directly, func() shows up in myprogram‘s symbols as it should:

gcc -Wl,--export-dynamic -o myprogram *.o libconvenience/*.o `pkg-config --libs somelibraries`

If I add a dummy call to func() somewhere in myprogram, then func() also shows up in myprogram‘s symbols. But I thought that --export-dynamic was supposed to export all symbols regardless of whether they were used in the program or not!

I am using automake 1.11.1 and gcc 4.5.1 on Fedora 14. I am also using Libtool 2.2.10 to build plugin.so (but not the convenience library.)

I didn’t forget to put -Wl,--export-dynamic in myprogram_LDFLAGS, nor did I forget to put the source that contains func() in libconvenience_a_SOURCES (some Googling suggests that these are common causes of this problem.)

Can somebody help me understand what is going on here?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-18T03:03:21+00:00Added an answer on May 18, 2026 at 3:03 am

    I managed to solve it. It was this note from John Calcote’s excellent Autotools book that pointed me in the right direction:

    Linkers add to the binary product every object file specified explicitly on the command line, but they only extract from archives those object files that are actually referenced in the code being linked.

    To counteract this behavior, one can use the --whole-archive flag to libtool. However, this causes all the symbols from all the system libraries to be pulled in also, causing lots of double symbol definition errors. So --whole-archive needs to be right before libconvenience.a on the linker command line, and it needs to be followed by --no-whole-archive so that the other libraries aren’t treated that way. This is a bit difficult since automake and libtool don’t really guarantee keeping your flags in the same order on the command line, but this line in Makefile.am did the trick:

    myprogram_LDFLAGS = -Wl,--export-dynamic \
        -Wl,--whole-archive,libconvenience/libconvenience.a,--no-whole-archive
    
    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I have some code which I am making available via RMI. If my program
I have a program which embeds both python2 and python3 interpreters. The libpython shared
I have c# program which writes an xml file to C: disk. I published
I would like to have a GtkTextView in my (Python) program which shows text
I have made a program in Java which is used to collect medical data
I have a custom shell program in which I have included signal.h , unistd.h
I have a login.jsp page which contains a login form. Once logged in the
I have a program which plays three .wav files synchronously when a button is
I have developed a program which makes use of serial programming to read and
In my program I have one array with 25 double values 0.04 When I

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.