Re: [Mingw-w64-public] Question about the undercore in svn
On Sun, Mar 21, 2010 at 8:31 PM, NightStrike nightstr...@gmail.com wrote: On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler dougsem...@gmail.com wrote: On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler dougsem...@gmail.com wrote: Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The target DLLs for things like libstdc++, etc are installed into the completely wrong spot due to a -bindir parameter in the libtool portion of the DLL makefiles. They are installed into the host's binary directory (which makes no sense to me at all - by the way I use a different -prefix and -exec-prefix), they cannot be overridden by the --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden and which I have working multilib with a minor patch to gcc/config/t-cygming), nor do they obey the version specific runtime libs directory like the native toolchain does. In addition, the mulitlib install can clobber the dlls in that (wrong) bindir with the wrong arch type (the 32bit install puts the 64 bit version there after all is said and done). Jon Y has a patch for all of that. Given that the trunk of GCC is in stage 4, I wouldn't expect any of this to be fixed prior to the release even if patches were submitted since I wouldn't expect this to be classified as a P1 issue (I don't think the w64-mingw32 toolchain is considered to be a primary target, is it?) Yeah, it's not getting fixed in 4.5. And no, we aren't even a secondary target :( My frustration right now is that the GCC trunk has been in stage 4 since December...aside from the fact that I would be wary personally of moving to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for these targets... After saying all that, the documentation about multilib should maybe have some caveats... Well, to be fair, we never advertised that it even exists... so. In both how-to-build docs, yes, you do :) Oh... well, hmm We should probably change that. In my defense, I've been away for a while :) I know that there was the the tools now track gcc statement and no more need to patch gcc. One of the problems really is going to be requiring the use of the 4.6 trunk to get the correct behavior for installation of the toolchain (multilib notwithstanding, I still feel the installation of the target DLLs is also woefully incorrect, so I presume the patch mentioned above does that as well) unless there are also plans to backport them to 4.5, which I would doubt. I would never use the stage 1,2, or 3 trunks to build production code (well, maybe the stage 3 depending on the issues in it)-- they are just too unstable --which means I'll track the 4.5 branch for quite a while. There's a few choices. Foremost, I would bribe Kai into getting this committed to 4.6 the moment it opens up into stage 1. That way, you are essentially using 4.5+patches, as opposed to somewhere in the middle of stage 1 4.6, which will have a lot more churn in the code. The best way to do that would be to have the binutils side already done. Beyond that... just grin and bear it? I dunno.. I'm open to suggestions. How do you want us to support you? Oh, I don't need you to support me in particular...I'm a pretty smart guy :) ... I just don't like reinventing the wheel is all :) In fact I'd be willing to volunteer to help with issues like this (in what little free time I have that is) - at the least on discussing things and at the most suggesting ideas or submitting patches for discussion. I'm still waiting for FSF paperwork myself so that I can do things on the binutils side, and I'll probably do FSF paperwork on the gcc side as well so that anything I run into can be at least submitted for comment without problem.. The biggest thing right now is that there are three projects that are interlinked...a change in behavior in one may require a change in all three of binutils, gcc, and the runtime...and really, where do you discuss those changes, all three lists? Even something as seemingly small as the underscore stuff for x64 is something that cascades really quickly... For example, the underscore stuff: the binutils ld right now doesn't support turning it off without a patch, which means that import and export objects can't be built during link without the option (you get a bunch of 'cannot export' stuff) Even with the patch, gcc has the -fno-leading-underscore option, but if you build mingw x64 with the no leading underscores, you have to remember to build everything (from target libraries to your own code) from that point forward with that option, or you need to patch gcc to default to no leading underscore on 64 bit, which has its own set of problems. but that leads to: gcc will still not link 64 bit dlls correctly without being patched, because the entry point will no longer be correct in the spec file. In addition, there's still
Re: [Mingw-w64-public] Question about the undercore in svn
On Mon, Mar 22, 2010 at 3:22 PM, Doug Semler dougsem...@gmail.com wrote: On Sun, Mar 21, 2010 at 8:31 PM, NightStrike nightstr...@gmail.com wrote: On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler dougsem...@gmail.com wrote: On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler dougsem...@gmail.com wrote: Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The target DLLs for things like libstdc++, etc are installed into the completely wrong spot due to a -bindir parameter in the libtool portion of the DLL makefiles. They are installed into the host's binary directory (which makes no sense to me at all - by the way I use a different -prefix and -exec-prefix), they cannot be overridden by the --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden and which I have working multilib with a minor patch to gcc/config/t-cygming), nor do they obey the version specific runtime libs directory like the native toolchain does. In addition, the mulitlib install can clobber the dlls in that (wrong) bindir with the wrong arch type (the 32bit install puts the 64 bit version there after all is said and done). Jon Y has a patch for all of that. Given that the trunk of GCC is in stage 4, I wouldn't expect any of this to be fixed prior to the release even if patches were submitted since I wouldn't expect this to be classified as a P1 issue (I don't think the w64-mingw32 toolchain is considered to be a primary target, is it?) Yeah, it's not getting fixed in 4.5. And no, we aren't even a secondary target :( My frustration right now is that the GCC trunk has been in stage 4 since December...aside from the fact that I would be wary personally of moving to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for these targets... After saying all that, the documentation about multilib should maybe have some caveats... Well, to be fair, we never advertised that it even exists... so. In both how-to-build docs, yes, you do :) Oh... well, hmm We should probably change that. In my defense, I've been away for a while :) I know that there was the the tools now track gcc statement and no more need to patch gcc. One of the problems really is going to be requiring the use of the 4.6 trunk to get the correct behavior for installation of the toolchain (multilib notwithstanding, I still feel the installation of the target DLLs is also woefully incorrect, so I presume the patch mentioned above does that as well) unless there are also plans to backport them to 4.5, which I would doubt. I would never use the stage 1,2, or 3 trunks to build production code (well, maybe the stage 3 depending on the issues in it)-- they are just too unstable --which means I'll track the 4.5 branch for quite a while. There's a few choices. Foremost, I would bribe Kai into getting this committed to 4.6 the moment it opens up into stage 1. That way, you are essentially using 4.5+patches, as opposed to somewhere in the middle of stage 1 4.6, which will have a lot more churn in the code. The best way to do that would be to have the binutils side already done. Beyond that... just grin and bear it? I dunno.. I'm open to suggestions. How do you want us to support you? Oh, I don't need you to support me in particular...I'm a pretty smart guy :) ... I just don't like reinventing the wheel is all :) In fact I'd be willing to volunteer to help with issues like this (in what little free time I have that is) - at the least on discussing things and at the most suggesting ideas or submitting patches for discussion. I'm still waiting for FSF paperwork myself so that I can do things on the binutils side, and I'll probably do FSF paperwork on the gcc side as well so that anything I run into can be at least submitted for comment without problem.. The biggest thing right now is that there are three projects that are interlinked...a change in behavior in one may require a change in all three of binutils, gcc, and the runtime...and really, where do you discuss those changes, all three lists? Even something as seemingly small as the underscore stuff for x64 is something that cascades really quickly... For example, the underscore stuff: the binutils ld right now doesn't support turning it off without a patch, which means that import and export objects can't be built during link without the option (you get a bunch of 'cannot export' stuff) Even with the patch, gcc has the -fno-leading-underscore option, but if you build mingw x64 with the no leading underscores, you have to remember to build everything (from target libraries to your own code) from that point forward with that option, or you need to patch gcc to default to no leading underscore on 64 bit, which has its own set of problems. but that leads to: gcc will still not link 64 bit dlls correctly without being
Re: [Mingw-w64-public] Question about the undercore in svn
On Mon, Mar 22, 2010 at 3:39 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/3/22 Doug Semler dougsem...@gmail.com: On Sun, Mar 21, 2010 at 8:31 PM, NightStrike nightstr...@gmail.com wrote: On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler dougsem...@gmail.com wrote: Well, in fact is this entry-point a no issue. By a recent patch, ld is able to select the proper entry-point without the need of specifying the -e entry. So this argument is in fact deprecated. Major pain here is the backward-compatibility necessary for older binutils. Buf for 4.6 I would prefer to make a crued break in support of older binutils versions (at least if configure for using no-underscore variant). In light of that - the patch for ld --no-leading-underscores doesn't work if you don't patch gcc to handle that...because the linker will select default entry of 1000 because it isn't able to find _dllmaincrtstar...@12 that is passed by gcc as the desired entry point. I guess the logic for the entry point in the linker could be looked at though... -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Question about the undercore in svn
Quick question: Are you sure you want to disable the leading underscore on the 32bit side with the --disable-leading-underscore and multilib? Looking at it (without testing it, that is), it doesn't seem to me that it is appropriate... -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Question about the undercore in svn
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote: Well, this is a problem, yes. It only affects the multilib builds, though, which don't really work anyway without a lot of effort. And this will all be fixed for 4.6, o we won't need to worry about it. If users really want it, though, I can rework things to exclude 32-bit entirely. It's just a little messy in Makefile.am. On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler dougsem...@gmail.com wrote: Quick question: Are you sure you want to disable the leading underscore on the 32bit side with the --disable-leading-underscore and multilib? Looking at it (without testing it, that is), it doesn't seem to me that it is appropriate... I think the flag really should be added to the lib64 versions in the makefiles. Otherwise things would go far messier the may think of. Besides that, there really is no way to tell the user as to how the crt was actually compiled. If there were a config header installed from within the crt build, maybe.. -- Ozkan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Question about the undercore in svn
2010/3/21 Ozkan Sezer seze...@gmail.com: On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote: Well, this is a problem, yes. It only affects the multilib builds, though, which don't really work anyway without a lot of effort. And this will all be fixed for 4.6, o we won't need to worry about it. If users really want it, though, I can rework things to exclude 32-bit entirely. It's just a little messy in Makefile.am. On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler dougsem...@gmail.com wrote: Quick question: Are you sure you want to disable the leading underscore on the 32bit side with the --disable-leading-underscore and multilib? Looking at it (without testing it, that is), it doesn't seem to me that it is appropriate... I think the flag really should be added to the lib64 versions in the makefiles. Otherwise things would go far messier the may think of. I agree, that it maybe gets for x86 much messier. And if possible, it would be better to have this underscoring just active for x64. Besides that, there really is no way to tell the user as to how the crt was actually compiled. If there were a config header installed from within the crt build, maybe.. Hmm, for what this header should be? I see the issue that an user can't see directly by which option for underscoring the crt was built, but for this a header makes also no sense. To detect this a call of nm reveals, if underscoring was active or not. I don't think that we should introduce for this something in configure. The header itself aren't affected, as they are checking the underscoring mode of gcc directly. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Question about the undercore in svn
On Sun, Mar 21, 2010 at 7:55 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/3/21 Ozkan Sezer seze...@gmail.com: On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote: Well, this is a problem, yes. It only affects the multilib builds, though, which don't really work anyway without a lot of effort. And this will all be fixed for 4.6, o we won't need to worry about it. If users really want it, though, I can rework things to exclude 32-bit entirely. It's just a little messy in Makefile.am. On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler dougsem...@gmail.com wrote: Quick question: Are you sure you want to disable the leading underscore on the 32bit side with the --disable-leading-underscore and multilib? Looking at it (without testing it, that is), it doesn't seem to me that it is appropriate... I think the flag really should be added to the lib64 versions in the makefiles. Otherwise things would go far messier the may think of. I agree, that it maybe gets for x86 much messier. And if possible, it would be better to have this underscoring just active for x64. You mean that we should make no-underscore the default for x64? Besides that, there really is no way to tell the user as to how the crt was actually compiled. If there were a config header installed from within the crt build, maybe.. Hmm, for what this header should be? I see the issue that an user can't see directly by which option for underscoring the crt was built, but for this a header makes also no sense. To detect this a call of nm reveals, if underscoring was active or not. I don't think that we should introduce for this something in configure. The header itself aren't affected, as they are checking the underscoring mode of gcc directly. Yes, _mingw_mac.h does that, figures what mode gcc is currently in. A generated header from crt compile time would be designed to indicate how it was compiled would be helpful to user: Suppose you compile a tree but the result was a link failure after one or two hours, how many remaining teeth would the user have after such an experience? Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Ozkan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Question about the undercore in svn
2010/3/21 Doug Semler dougsem...@gmail.com: On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote: 2010/3/21 Ozkan Sezer seze...@gmail.com: On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote: Well, this is a problem, yes. It only affects the multilib builds, though, which don't really work anyway without a lot of effort. And this will all be fixed for 4.6, o we won't need to worry about it. If users really want it, though, I can rework things to exclude 32-bit entirely. It's just a little messy in Makefile.am. On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler dougsem...@gmail.com wrote: Quick question: Are you sure you want to disable the leading underscore on the 32bit side with the --disable-leading-underscore and multilib? Looking at it (without testing it, that is), it doesn't seem to me that it is appropriate... I think the flag really should be added to the lib64 versions in the makefiles. Otherwise things would go far messier the may think of. I agree, that it maybe gets for x86 much messier. And if possible, it would be better to have this underscoring just active for x64. Besides that, there really is no way to tell the user as to how the crt was actually compiled. If there were a config header installed from within the crt build, maybe.. Hmm, for what this header should be? I see the issue that an user can't see directly by which option for underscoring the crt was built, but for this a header makes also no sense. To detect this a call of nm reveals, if underscoring was active or not. I don't think that we should introduce for this something in configure. The header itself aren't affected, as they are checking the underscoring mode of gcc directly. It actually gets even messier. Currently, the ld in binutils assumes that x64 should always have underscores, which means that import and export symbols libraries are generated incorrectly from there. There's no way currently to configure at compile time or pass at runtime this flag to ld (unlike dlltool which at least has this). Nor is there a way to pass the flag from the gcc driver to the linker. Yes, ld is at the moment the app not supporting options for overriding underscore mode. The sad thing about ld is that is uses hardcoded values in script-templates instead of using the target default. By this issue in design it is much work to allow such an option. The last patches I did for this were stopped at the point (but patch is now in bfd) to have an bfd API to query undescoring mode by internal bfd-name. I didn't continued on this reasoned by lack of time. I have patched ld (and the binutils configury) to accept a configure time parameter for default behavior, as well as adding a parameter to override the behavior from ld (which is more important). I am still waiting for copyright assignment paperwork from the FSF before I submit it for comment to the binutils list (not sure that this patch would be accepted though). I think there is in general a good chance for this. And the necessary change for gcc 4.6 (which is pretty small one) I'll approve as soon as issue in binutils are solved. This is in addition to the other two patches I have in my own pipeline with respect to the library long names (NULL terminated in PE-COFF) and the parameter to make ld import libraries generate the same archive member file name so that they can be picked up by the native linker (and I probably should figure a good way to patch dlltool to do this as well, but it uses a different method of generating import libraries...) Yeah, dlltool uses here gas to generate the import-library. IMHO it should support the same generation mechanism without gas (like ld), too. And this should get default. By this the initial idea is to move the import-library generation code into bfd's coff code. So we could avoid double implementation. Additionally it would allow to support in future the ANON-object file format version 0 (new import descriptor), too. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Question about the undercore in svn
On 3/22/2010 07:24, Doug Semler wrote:
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semlerdougsem...@gmail.com wrote:
Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
target DLLs for things like libstdc++, etc are installed into the
completely wrong spot due to a -bindir parameter in the libtool portion
of the DLL makefiles. They are installed into the host's binary
directory (which makes no sense to me at all - by the way I use a
different -prefix and -exec-prefix), they cannot be overridden by the
--with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden
and which I have working multilib with a minor patch to
gcc/config/t-cygming), nor do they obey the version specific runtime
libs directory like the native toolchain does. In addition, the
mulitlib install can clobber the dlls in that (wrong) bindir with the
wrong arch type (the 32bit install puts the 64 bit version there after
all is said and done).
Jon Y has a patch for all of that.
Given that the trunk of GCC is in stage 4, I wouldn't expect any of this
to be fixed prior to the release even if patches were submitted since I
wouldn't expect this to be classified as a P1 issue (I don't think the
w64-mingw32 toolchain is considered to be a primary target, is it?)
Yeah, it's not getting fixed in 4.5. And no, we aren't even a
secondary target :(
My frustration right now is that the GCC trunk has been in stage 4 since
December...aside from the fact that I would be wary personally of moving
to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for
these targets...
After saying all that, the documentation about multilib should maybe have
some caveats...
Well, to be fair, we never advertised that it even exists... so.
In both how-to-build docs, yes, you do :)
I know that there was the the tools now track gcc statement and no more
need to patch gcc. One of the problems really is going to be requiring the
use of the 4.6 trunk to get the correct behavior for installation of the
toolchain (multilib notwithstanding, I still feel the installation of the
target DLLs is also woefully incorrect, so I presume the patch mentioned above
does that as well) unless there are also plans to backport them to 4.5, which
I would doubt. I would never use the stage 1,2, or 3 trunks to build
production code (well, maybe the stage 3 depending on the issues in it)-- they
are just too unstable --which means I'll track the 4.5 branch for quite a
while.
Don't know what I'll do...wait for the patch(es) to be applied, do the work
myself, or just deal with it (using nonmultilib, moving the files to where they
should be, and modifying the installed .la files correctly...)
OK...vent mode off :)
Hi,
here are the patches to make the dlls not clash, v1.patch for
libtool, gcc_multilib.patch for gcc. The dlls are prefixed w32 and
w64 respectively.
You'll need to regenerate the gcc configury, particularly for the
target support libs, after installing a patched version of libtool.
I'm still waiting for the FSF paperwork to be done.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 80a1ff3..45798fc 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4215,6 +4215,28 @@ func_mode_link ()
continue
;;
+ -m32)
+ archive_cmds=$archive_cmds -m32
+ case $host in
+ *-w64-mingw*)
+ MULTILIB_PREFIX=l32
+ ;;
+ *) ;;
+ esac
+ continue
+ ;;
+
+ -m64)
+ archive_cmds=$archive_cmds -m64
+ case $host in
+ *-w64-mingw*)
+ MULTILIB_PREFIX=l64
+ ;;
+ *) ;;
+ esac
+ continue
+ ;;
+
-no-undefined)
allow_undefined=no
continue
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 29f1222..f6bb69a 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2084,6 +2084,7 @@ BEGIN {RS= ; FS=/|\n;} {
else
sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
fi])
+MULTILIB_PREFIX=
library_names_spec=
libname_spec='lib$name'
soname_spec=
@@ -2227,6 +2228,22 @@ m4_if([$1], [],[
mingw* | cegcc*)
# MinGW DLLs use traditional 'lib' prefix
soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ case $host_vendor in
+w64)
+soname_spec='`echo ${libname} | sed -e
's/^lib/\${MULTILIB_PREFIX}/'``echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+case $host in
+x86_64-*)
+ MULTILIB_PREFIX=l64
+;;
+i?86-*)
+ MULTILIB_PREFIX=l32
+;;
+esac
+;;
+ *)
+soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ ;;
+ esac
;;
pw32*)
# pw32 DLLs use 'pw' prefix rather than 'lib'
@@ -2705,6 +2722,8 @@ _LT_DECL([], [libname_spec], [1], [Format of
