Re: [Mingw-users] Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLibetc..."
Guido Draheim wrote:
>
> Max Bowsher wrote:
> > Guido Draheim wrote:
> >
> >>How old may a gcc/binutils pair be? My oldest crosscompilers
> >>are gcc 2.95.3 and ld --version reports 2.11.90.8. And for
> >>all I know, these are in fact the oldest versions around,
> >>no one want to go back beyond, I guess.
> >>
> >>Is that enough, Max?
> >
> >
> > Test:
> >
> > $ echo '__declspec(dllexport) void foo () {}' > foo.c
> > $ gcc -shared foo.c -o foo.dll
> > $ objdump -p foo.dll | fgrep -A 5 Characteristics
>
> The real problem is in a `gcc -shared foo.c -o foo.dll -lz`
> and whether gcc can find the zlib dll, and link it even
> when no .dll.a is available, with just the dll being present.
>
libfoo.dll.a should represent the import library. libfoo.a should
represent the static library. libfoo.dll is also able to be used for
the import library. I forget the ld search order, libfoo.dll.a,
libfoo.a then libfoo.dll or is it libfoo.dll.a, libfoo.dll then
libfoo.a, IIRC, it's the former and not the latter. If that is the
case a libfoo.a that is truely a static library will be used instead of
the shared library libfoo.dll.
> The zlib is probably a good example - quite some portable
> software makes use of it, including my http://zziplib.sf.net
>
Then you should know.
Earnie.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLibetc..."
Max Bowsher wrote: > > Guido Draheim wrote: > > (B) final $dlname to ../bin/$dlname - interesting way to do about this > > but probably interfering with autoconfed installpath specs (I for > > one use an ac-macro to make the default of $libdir the same as > > $bindir which has the effect of what's needed - to bring the dlls > > into $PATH). > > I agree that this is inelegant. Ideally, we would calculate the relative path to > bindir from libdir, but I don't know how to do that. Anyone? > ls `gcc -print-file-name=specs | sed -e 's/specs//'`../../../../bin > > (C) what's that install-number-increment-sedscript about? > > The give-dlls-execute-permissions-sedscript? Because on Cygwin with ntsec, the > dll is installed without execute permission, so cannot be used. > So isn't needed for mingw32 but is needed for cygwin. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLibetc..."
Guido Draheim wrote: > (A) the sys_lib_search_path spec gets hardcoded to the cygwin path. > no go on mingw cross. $CC -print-search-dirs rules. I wish I knew why this hack is required on Cygwin > (B) final $dlname to ../bin/$dlname - interesting way to do about this > but probably interfering with autoconfed installpath specs (I for > one use an ac-macro to make the default of $libdir the same as > $bindir which has the effect of what's needed - to bring the dlls > into $PATH). I agree that this is inelegant. Ideally, we would calculate the relative path to bindir from libdir, but I don't know how to do that. Anyone? > (C) what's that install-number-increment-sedscript about? The give-dlls-execute-permissions-sedscript? Because on Cygwin with ntsec, the dll is installed without execute permission, so cannot be used. > (D) is that a shellscript to make a .def file and compile it? > cute... but let's see if it works cross. No idea - I just copied and pasted from the existing code in libtool.m4. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
