New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix to avoid needing -all_load or -force_load linker flags. #406

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@echamberlain

echamberlain commented Feb 14, 2011

The changes in this pull request cause the linker to load the object files without the need to use the -all_load or -force_load flags.

We include other libraries that break if we use -all_load. We also want to avoid using -force_load, so that the libraries will symbolicate properly when we debug.

@jwang

This comment has been minimized.

Show comment
Hide comment
@jwang

jwang Feb 14, 2011

Contributor

Hmm. This is an interesting one. I use other libraries as well. Can you tell me which ones are causing the problem? We want to make sure we're fully compatible with other libraries and I think this may be easier resolved through some other configuration if possible.

Contributor

jwang commented Feb 14, 2011

Hmm. This is an interesting one. I use other libraries as well. Can you tell me which ones are causing the problem? We want to make sure we're fully compatible with other libraries and I think this may be easier resolved through some other configuration if possible.

@echamberlain

This comment has been minimized.

Show comment
Hide comment
@echamberlain

echamberlain Feb 14, 2011

The conflict is with xmppframework, specifically libidn.

echamberlain commented Feb 14, 2011

The conflict is with xmppframework, specifically libidn.

@elliotb

This comment has been minimized.

Show comment
Hide comment
@elliotb

elliotb Feb 14, 2011

The Burstly ad mediation library also conflicts with -all_load.

elliotb commented Feb 14, 2011

The Burstly ad mediation library also conflicts with -all_load.

@echamberlain

This comment has been minimized.

Show comment
Hide comment
@echamberlain

echamberlain Feb 14, 2011

More info, libidn.a is a fat universal library when we add the -all_load flag, we get the following errors:

Undefined symbols:
"_libiconv_open", referenced from:
_str_iconv in libidn.a(striconv.o)
"_libintl_dgettext", referenced from:
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
"_libiconv", referenced from:
_str_cd_iconv in libidn.a(striconv.o)
_str_cd_iconv in libidn.a(striconv.o)
_str_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
"_libiconv_close", referenced from:
_str_iconv in libidn.a(striconv.o)
_str_iconv in libidn.a(striconv.o)
"_libintl_bindtextdomain", referenced from:
_idna_strerror in libidn.a(strerror-idna.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_tld_strerror in libidn.a(strerror-tld.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

echamberlain commented Feb 14, 2011

More info, libidn.a is a fat universal library when we add the -all_load flag, we get the following errors:

Undefined symbols:
"_libiconv_open", referenced from:
_str_iconv in libidn.a(striconv.o)
"_libintl_dgettext", referenced from:
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_idna_strerror in libidn.a(strerror-idna.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
_tld_strerror in libidn.a(strerror-tld.o)
"_libiconv", referenced from:
_str_cd_iconv in libidn.a(striconv.o)
_str_cd_iconv in libidn.a(striconv.o)
_str_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
_mem_cd_iconv in libidn.a(striconv.o)
"_libiconv_close", referenced from:
_str_iconv in libidn.a(striconv.o)
_str_iconv in libidn.a(striconv.o)
"_libintl_bindtextdomain", referenced from:
_idna_strerror in libidn.a(strerror-idna.o)
_pr29_strerror in libidn.a(strerror-pr29.o)
_punycode_strerror in libidn.a(strerror-punycode.o)
_stringprep_strerror in libidn.a(strerror-stringprep.o)
_tld_strerror in libidn.a(strerror-tld.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

@jverkoey

This comment has been minimized.

Show comment
Hide comment
@jverkoey

jverkoey Feb 16, 2011

Contributor

I've seen this error before myself and outside of the -force_load flag which has its own problems, there doesn't seem to be a particularly effective solution. I think this might very well be one of the best solutions we have so far that still allows us to debug Three20 code.

Are there any side effects to doing this that we should be aware of?

Contributor

jverkoey commented Feb 16, 2011

I've seen this error before myself and outside of the -force_load flag which has its own problems, there doesn't seem to be a particularly effective solution. I think this might very well be one of the best solutions we have so far that still allows us to debug Three20 code.

Are there any side effects to doing this that we should be aware of?

@echamberlain

This comment has been minimized.

Show comment
Hide comment
@echamberlain

echamberlain Feb 16, 2011

None I can think of, other than developers being aware of having to add the code fix to any new categories referencing objects in static libraries.

We've been using this fix in our App Store live code since early December without any issues.

echamberlain commented Feb 16, 2011

None I can think of, other than developers being aware of having to add the code fix to any new categories referencing objects in static libraries.

We've been using this fix in our App Store live code since early December without any issues.

@jverkoey

This comment has been minimized.

Show comment
Hide comment
@jverkoey

jverkoey Feb 16, 2011

Contributor

I think that minor inconvenience is worth it for this particular case. In the future I hope to add a linter to the Three20 internal build process so things like this could be caught and flagged anyway.

Let's merge this one in to 1.0.4.

Contributor

jverkoey commented Feb 16, 2011

I think that minor inconvenience is worth it for this particular case. In the future I hope to add a linter to the Three20 internal build process so things like this could be caught and flagged anyway.

Let's merge this one in to 1.0.4.

@jverkoey

This comment has been minimized.

Show comment
Hide comment
@jverkoey

jverkoey Feb 17, 2011

Contributor

Not particularly sure. Barring any easier solution, just close this pull request and open a new one :)

Contributor

jverkoey commented Feb 17, 2011

Not particularly sure. Barring any easier solution, just close this pull request and open a new one :)

@jwang

This comment has been minimized.

Show comment
Hide comment
@jwang

jwang Feb 17, 2011

Contributor

it shall be done.

Contributor

jwang commented Feb 17, 2011

it shall be done.

@jwang

This comment has been minimized.

Show comment
Hide comment
@jwang

jwang Feb 17, 2011

Contributor

I'm going to merge this into 1.0.4 but I'm also marking it as a future follow-up item as I would like to investigate more elegant solutions to this and will also see what I can get out of Apple's team on recommended solution.

Contributor

jwang commented Feb 17, 2011

I'm going to merge this into 1.0.4 but I'm also marking it as a future follow-up item as I would like to investigate more elegant solutions to this and will also see what I can get out of Apple's team on recommended solution.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment