Re: [Mingw-w64-public] Include paths, float.h
On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler wrote: > On Sun, 21 Mar 2010 19:22:48 NightStrike wrote: >> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer wrote: >> > For some reason yet unknown to me, the gcc-provided headers >> > have priority over the system provided headers and float.h is >> > especially problematic: Not installing or deleting it is the solution, >> > at least for now. >> >> If gcc headers didn't take priority, then fixincludes wouldn't work. >> >> The real question is why gcc forces changes to system headers instead >> of working with system headers. >> > > Does gcc even necessarily have the system headers available to it on a clean > system during a build? I don't think so...which means that gcc may not know > about the system headers when it runs through the stage of installation... > > In other words, for it to even work with the system headers, the system > headers have to be installed correctly before you do the first make > install-gcc > during a bootstrap... > > (and I know the one howto build doc says install the headers first, but > unfortunately building the toolchain does not fail if you do NOT do this...) > Building the toolchain does in fact fail. Just, not at the all-gcc stage (the bootstrapping stage). Do a make all-gcc. When it finishes, do "make all". It'll die immediately asking for a valid sysroot. -- Download Intel® 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 Semler 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 li
Re: [Mingw-w64-public] Question about the undercore in svn
On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote: > On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: >> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler 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? > 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 :) > -- Download Intel® 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] Include paths, float.h
On Sun, 21 Mar 2010 19:22:48 NightStrike wrote: > On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer wrote: > > For some reason yet unknown to me, the gcc-provided headers > > have priority over the system provided headers and float.h is > > especially problematic: Not installing or deleting it is the solution, > > at least for now. > > If gcc headers didn't take priority, then fixincludes wouldn't work. > > The real question is why gcc forces changes to system headers instead > of working with system headers. > Does gcc even necessarily have the system headers available to it on a clean system during a build? I don't think so...which means that gcc may not know about the system headers when it runs through the stage of installation... In other words, for it to even work with the system headers, the system headers have to be installed correctly before you do the first make install-gcc during a bootstrap... (and I know the one howto build doc says install the headers first, but unfortunately building the toolchain does not fail if you do NOT do this...) -- Download Intel® 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, 21 Mar 2010 18:37:12 NightStrike wrote: > On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler 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 :) -- Download Intel® 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] Include paths, float.h
On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer wrote: > For some reason yet unknown to me, the gcc-provided headers > have priority over the system provided headers and float.h is > especially problematic: Not installing or deleting it is the solution, > at least for now. If gcc headers didn't take priority, then fixincludes wouldn't work. The real question is why gcc forces changes to system headers instead of working with system headers. -- Download Intel® 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 2:10 PM, Doug Semler 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. -- Download Intel® 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] Include paths, float.h
On Sun, Mar 21, 2010 at 10:42 PM, Dave Camarillo
wrote:
> Hello, I'm having a little trouble with the include paths used by mingw-w64
> and was hoping for some insight... I have this chunk of code compiling
> correctly under the normal mingw system, but have some problems with include
> search paths with the w64 version... As far as I can tell, it's just pulling
> in the wrong version of float.h? but since it's system include paths, I'm
> not entirely sure how to get it to use the right paths After inspecting
> the header it looks like this is an MS specific feature, thus the reason
> it's not in the normal GCC header. I'm actually trying to compile a larger
> linear-algebra library, but it wants the MS specifics when it's being
> compiled on a MS box. Trivial source code, error messages and debug output
> are below...
>
> Thoughts?
>
>
> Thanks,
> -d
>
> #include
> int main(int argc, char* argv) {
> long i = _EM_DENORMAL;
> return(0);
> }
>
>
> $ gcc -c test.c
> test.c: In function 'main':
> test.c:5:11: error: '_EM_DENORMAL' undeclared (first use in this function)
> test.c:5:11: error: (Each undeclared identifier is reported only once
> test.c:5:11: error: for each function it appears in.)
>
>
> $ gcc -M -c test.c
> test.o: test.c \
> c:\msys\system64\bin-4.5.0\../lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h
Just delete this particular one from your installation ...
>
>
> $ cat /c/msys/system64/lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h |
> grep EM_DENORMAL
>
>
>
> There is a different header that has what I'm looking for:
>
> $ cat /c/msys/system64/x86_64-w64-mingw32/include/float.h | grep EM_DENORMAL
> #define _EM_DENORMAL 0x0008
... and this will be included by your source, instead.
For some reason yet unknown to me, the gcc-provided headers
have priority over the system provided headers and float.h is
especially problematic: Not installing or deleting it is the solution,
at least for now.
--
Ozkan
--
Download Intel® 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] Include paths, float.h
Hello, I'm having a little trouble with the include paths used by mingw-w64
and was hoping for some insight... I have this chunk of code compiling
correctly under the normal mingw system, but have some problems with include
search paths with the w64 version... As far as I can tell, it's just pulling
in the wrong version of float.h? but since it's system include paths, I'm
not entirely sure how to get it to use the right paths After inspecting
the header it looks like this is an MS specific feature, thus the reason
it's not in the normal GCC header. I'm actually trying to compile a larger
linear-algebra library, but it wants the MS specifics when it's being
compiled on a MS box. Trivial source code, error messages and debug output
are below...
Thoughts?
Thanks,
-d
#include
int main(int argc, char* argv) {
long i = _EM_DENORMAL;
return(0);
}
$ gcc -c test.c
test.c: In function 'main':
test.c:5:11: error: '_EM_DENORMAL' undeclared (first use in this function)
test.c:5:11: error: (Each undeclared identifier is reported only once
test.c:5:11: error: for each function it appears in.)
$ gcc -M -c test.c
test.o: test.c \
c:\msys\system64\bin-4.5.0\../lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h
$ cat /c/msys/system64/lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h |
grep EM_DENORMAL
There is a different header that has what I'm looking for:
$ cat /c/msys/system64/x86_64-w64-mingw32/include/float.h | grep EM_DENORMAL
#define _EM_DENORMAL0x0008
--
Download Intel® 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 :
> On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote:
>> 2010/3/21 Ozkan Sezer :
>> > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike
> 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
> 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® 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, 21 Mar 2010 13:55:36 Kai Tietz wrote: > 2010/3/21 Ozkan Sezer : > > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike 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 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. 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). 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...) -- Download Intel® 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, 21 Mar 2010 13:21:12 NightStrike 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. > 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). 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?) 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... -- Download Intel® 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 wrote:
> 2010/3/21 Ozkan Sezer :
>> On Sun, Mar 21, 2010 at 7:21 PM, NightStrike 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 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® 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 :
> On Sun, Mar 21, 2010 at 7:21 PM, NightStrike 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 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® 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 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 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® 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
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 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... > > -- > Download Intel® 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 > -- Download Intel® 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® 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
