From: SourceForge.net <no...@so...> - 2005-09-28 21:33:46
|
Support Requests item #1307365, was opened at 2005-09-28 23:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Group: None Status: Open Priority: 5 Submitted By: Peter Ekberg (pekberg) Assigned to: Nobody/Anonymous (nobody) Summary: Const symbols in .text segment, nm outputs T (or t). Initial Comment: Hello! I have been looking at a problem in libtool. I would like to not be forced to use declspec(dllexport) and to not use a def file, but instead only require the standard symbol list which is specified with the -export-symbols libtool option, and then have libtool generate a correct def file for me. I.e. a def file which will create a correct import library for me even if data is exported. The method I used to fix this in Cygwin was to use the output from nm on all objects used to construct the library to find out which symbols are data symbols, and then use that info to filter the user-supplied list of desired exports so that DATA is appended to each symbol that is in fact a data symbol. This thread describes it: http://lists.gnu.org/archive/html/libtool-patches/2005- 09/msg00099.html However, for MinGW this method breaks down as const data is sometimes stored in the .text segment. So, nm can't be used to (reliably) determine whether a symbol is data or a function. Is there a reason why MinGW (gcc 3.2.3) behaves differently from Cygwin (gcc 3.4.4) in this regard? Can nm be 'fixed' to lie about data symbols in the .text segment and output some other char than T/t? Is this simply something that is different in gcc 3.2.3 and gcc 3.4.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-09-29 04:22:29
|
Support Requests item #1307365, was opened at 2005-09-29 09:33 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Group: None Status: Open Priority: 5 Submitted By: Peter Ekberg (pekberg) Assigned to: Nobody/Anonymous (nobody) Summary: Const symbols in .text segment, nm outputs T (or t). Initial Comment: Hello! I have been looking at a problem in libtool. I would like to not be forced to use declspec(dllexport) and to not use a def file, but instead only require the standard symbol list which is specified with the -export-symbols libtool option, and then have libtool generate a correct def file for me. I.e. a def file which will create a correct import library for me even if data is exported. The method I used to fix this in Cygwin was to use the output from nm on all objects used to construct the library to find out which symbols are data symbols, and then use that info to filter the user-supplied list of desired exports so that DATA is appended to each symbol that is in fact a data symbol. This thread describes it: http://lists.gnu.org/archive/html/libtool-patches/2005- 09/msg00099.html However, for MinGW this method breaks down as const data is sometimes stored in the .text segment. So, nm can't be used to (reliably) determine whether a symbol is data or a function. Is there a reason why MinGW (gcc 3.2.3) behaves differently from Cygwin (gcc 3.4.4) in this regard? Can nm be 'fixed' to lie about data symbols in the .text segment and output some other char than T/t? Is this simply something that is different in gcc 3.2.3 and gcc 3.4.4? ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2005-09-29 16:22 Message: Logged In: YES user_id=11494 mingw's gcc has put const data in .rdata since gcc-3.3.3, same as cygwin. In official gcc sources, the change was made in gcc-3.4.0 Look at the doc's for dlltool. It will create a .suitavle def from a list of objects like so dlltool --out-def foo.def --export-all ${OBJECTS} Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-09-29 04:25:10
|
Support Requests item #1307365, was opened at 2005-09-29 09:33 Message generated for change (Settings changed) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Group: None >Status: Closed Priority: 5 Submitted By: Peter Ekberg (pekberg) Assigned to: Nobody/Anonymous (nobody) Summary: Const symbols in .text segment, nm outputs T (or t). Initial Comment: Hello! I have been looking at a problem in libtool. I would like to not be forced to use declspec(dllexport) and to not use a def file, but instead only require the standard symbol list which is specified with the -export-symbols libtool option, and then have libtool generate a correct def file for me. I.e. a def file which will create a correct import library for me even if data is exported. The method I used to fix this in Cygwin was to use the output from nm on all objects used to construct the library to find out which symbols are data symbols, and then use that info to filter the user-supplied list of desired exports so that DATA is appended to each symbol that is in fact a data symbol. This thread describes it: http://lists.gnu.org/archive/html/libtool-patches/2005- 09/msg00099.html However, for MinGW this method breaks down as const data is sometimes stored in the .text segment. So, nm can't be used to (reliably) determine whether a symbol is data or a function. Is there a reason why MinGW (gcc 3.2.3) behaves differently from Cygwin (gcc 3.4.4) in this regard? Can nm be 'fixed' to lie about data symbols in the .text segment and output some other char than T/t? Is this simply something that is different in gcc 3.2.3 and gcc 3.4.4? ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-09-29 16:22 Message: Logged In: YES user_id=11494 mingw's gcc has put const data in .rdata since gcc-3.3.3, same as cygwin. In official gcc sources, the change was made in gcc-3.4.0 Look at the doc's for dlltool. It will create a .suitavle def from a list of objects like so dlltool --out-def foo.def --export-all ${OBJECTS} Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-09-29 12:57:19
|
Support Requests item #1307365, was opened at 2005-09-28 23:33 Message generated for change (Comment added) made by pekberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Group: None Status: Closed Priority: 5 Submitted By: Peter Ekberg (pekberg) Assigned to: Nobody/Anonymous (nobody) Summary: Const symbols in .text segment, nm outputs T (or t). Initial Comment: Hello! I have been looking at a problem in libtool. I would like to not be forced to use declspec(dllexport) and to not use a def file, but instead only require the standard symbol list which is specified with the -export-symbols libtool option, and then have libtool generate a correct def file for me. I.e. a def file which will create a correct import library for me even if data is exported. The method I used to fix this in Cygwin was to use the output from nm on all objects used to construct the library to find out which symbols are data symbols, and then use that info to filter the user-supplied list of desired exports so that DATA is appended to each symbol that is in fact a data symbol. This thread describes it: http://lists.gnu.org/archive/html/libtool-patches/2005- 09/msg00099.html However, for MinGW this method breaks down as const data is sometimes stored in the .text segment. So, nm can't be used to (reliably) determine whether a symbol is data or a function. Is there a reason why MinGW (gcc 3.2.3) behaves differently from Cygwin (gcc 3.4.4) in this regard? Can nm be 'fixed' to lie about data symbols in the .text segment and output some other char than T/t? Is this simply something that is different in gcc 3.2.3 and gcc 3.4.4? ---------------------------------------------------------------------- >Comment By: Peter Ekberg (pekberg) Date: 2005-09-29 14:57 Message: Logged In: YES user_id=972775 Thanks for the help! I will upgrade my installation and have a look at dlltool. Cheers, Peter ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-09-29 06:22 Message: Logged In: YES user_id=11494 mingw's gcc has put const data in .rdata since gcc-3.3.3, same as cygwin. In official gcc sources, the change was made in gcc-3.4.0 Look at the doc's for dlltool. It will create a .suitavle def from a list of objects like so dlltool --out-def foo.def --export-all ${OBJECTS} Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435 |