mingw-users

[Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

Hi,

 

my ultimate goal is to have a library libaddr2line.a for MinGW compilation.
If my understanding is correct, then the library bfd is required for this. 

 

To start with, compiling the mini test program 

<main.c>

#define PACKAGE "test"

#define PACKAGE_VERSION "x.y.z"

 

#include <stdio.h>

#include <bfd.h>

 

int main(int argc, char** argv)

{

    bfd_init();

 

    char* fn=argv[0];

    printf("exe: '%s'\n", fn);

 

    bfd* file = bfd_openr(fn, 0);

 

    if (!file)

        return 1;

 

    if (bfd_check_format(file, bfd_object))

        printf("object file\n");

    else

        printf("not object file\n");

 

    bfd_close(file);

 

    return 0;

}

</main.c>

 

with

              mingw32-g++.exe -o t.exe main.c -lbfd -lintl -liberty -lz 

 

should be fine, in principle, i.e. MinGW's bfd appears to depend on the
libraries intl, (l)iberty and z, at least. For MinGW compilation gcc needs
-LC:\MinGW\msys\1.0\lib for linking. But still, the MinGW compiler is
complaining:

 

c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libbfd.a(archive.o):(.text+0x
3f4): undefined reference to `filename_ncmp'

c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libbfd.a(archive.o):(.text+0x
1e48): undefined reference to `filename_ncmp'

c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libbfd.a(archive.o):(.text+0x
1ecc): undefined reference to `filename_ncmp'

c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libbfd.a(syms.o):(.text+0x735
): undefined reference to `filename_ncmp'

C:\MinGW\msys\1.0\lib\libiberty.a(getpwd.o):getpwd.c:(.text+0x2c): undefined
reference to `__errno'

C:\MinGW\msys\1.0\lib\libiberty.a(getpwd.o):getpwd.c:(.text+0x61): undefined
reference to `__errno'

C:\MinGW\msys\1.0\lib\libiberty.a(getpwd.o):getpwd.c:(.text+0xe3): undefined
reference to `__errno'

C:\MinGW\msys\1.0\lib\libiberty.a(hashtab.o):hashtab.c:(.text+0x10c):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(hashtab.o):hashtab.c:(.text+0x20c):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(hashtab.o):hashtab.c:(.text+0x323):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(hashtab.o):hashtab.c:(.text+0x403):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(hashtab.o):hashtab.c:(.text+0x9f9):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(hashtab.o):hashtab.c:(.text+0xc26): more
undefined references to `_impure_ptr' follow

C:\MinGW\msys\1.0\lib\libiberty.a(lrealpath.o):lrealpath.c:(.text+0x1b):
undefined reference to `realpath'

C:\MinGW\msys\1.0\lib\libiberty.a(unlink-if-ordinary.o):unlink-if-ordinary.c
:(.text+0x15): undefined reference to `lstat'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x28):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x57):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x88):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0xb8):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0xbd):
undefined reference to `environ'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x107):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x135):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x165):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x16a):
undefined reference to `environ'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x1cb):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x1f8):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x228):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x22d):
undefined reference to `environ'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x28c):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x2ba):
undefined reference to `_impure_ptr'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x2ea):
undefined reference to `sbrk'

C:\MinGW\msys\1.0\lib\libiberty.a(xmalloc.o):xmalloc.c:(.text+0x2ef):
undefined reference to `environ' 

 

Am I missing another library available in the MinGW collection and to be
linked with - or is there some other easy way to produce/download the
library (lib)addr2line.a?

 

Living on Win10 with mingw32-g++ 5.3.0. Happy to provide additional
information if needed.

 

Many thanks,

J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Eli Z. <el...@gn...>]

> From: "Jannick" <thi...@gm...>
> Date: Sat, 1 Oct 2016 14:15:10 +0200
> 
> mingw32-g++.exe -o t.exe main.c -lbfd -lintl -liberty -lz 
> 
> should be fine, in principle, i.e. MinGW’s bfd appears to depend on the libraries intl, (l)iberty and z, at least.
> For MinGW compilation gcc needs -LC:\MinGW\msys\1.0\lib for linking. But still, the MinGW compiler is
> complaining:
> 
> c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libbfd.a(archive.o):(.text+0x3f4): undefined reference to
> `filename_ncmp'


filename_ncmp is in libiberty.a, so I don't understand why you are
getting these unresolved externals.  Perhaps your libiberty.a is from
an old distribution?

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

Hi Eli,

Thanks for this.

> From: Eli Zaretskii [mailto:el...@gn...]
> Sent: Saturday, October 1, 2016 5:37 PM
> >
> > mingw32-g++.exe -o t.exe main.c -lbfd -lintl -liberty -lz
> >
> > should be fine, in principle, i.e. MinGW’s bfd appears to depend on the
> libraries intl, (l)iberty and z, at least.
> > For MinGW compilation gcc needs -LC:\MinGW\msys\1.0\lib for linking.
> > But still, the MinGW compiler is
> > complaining:
> >
> > c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libbfd.a(archive.o):(.t
> > ext+0x3f4): undefined reference to `filename_ncmp'
> 
> 
> filename_ncmp is in libiberty.a, so I don't understand why you are getting
> these unresolved externals.  Perhaps your libiberty.a is from an old
> distribution?

I am using the version of libliberty.a shipped with msys as part of MinGW. I reinstalled all of MinGW and
Msys with

	Mingw-get upgrade --reinstall --recursive

to use the latest versions available. Then libliberty.a (in C:\MinGW\msys\1.0\lib) has a file 
datestamp as of Jan 16, 2010, with a file size of 344kB. Supposedly this is outdated.

Notably, while libbfd.a is available in the MinGW library folder, liberty.a is not which is 
why I linked the version in the msys folder.

Is it thus possible that bfd & liberty in MinGW/Msys do not fit together?

Many thanks again,
J. 

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Keith M. <kei...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/10/16 17:25, Jannick wrote:
> I am using the version of libliberty.a shipped with msys as part
> of MinGW.

Pedantically, MSYS isn't part of MinGW; it's a development platform in
its own right, which is convenient to use in conjunction *with* MinGW.

> I reinstalled all of MinGW and Msys with
> 
> Mingw-get upgrade --reinstall --recursive
> 
> to use the latest versions available. Then libliberty.a (in

I guess you meant to say "libiberty.a" here?

> C:\MinGW\msys\1.0\lib) has a file datestamp as of Jan 16, 2010,
> with a file size of 344kB. Supposedly this is outdated.

It's the current version, for use by MSYS platform developers ONLY.
It isn't intended to be used by MinGW application developers; indeed,
it is completely incompatible with such usage.

> Notably, while libbfd.a is available in the MinGW library folder, 
> liberty.a is not which is why I linked the version in the msys 
> folder.

That was a grave error.  Indeed, why do you even have those MSYS libs
installed in the first place?  Unless you are (or aspire to become) an
MSYS platform developer, (in which case, you really should know better
than to misuse them so), you have absolutely no need for them.

> Is it thus possible that bfd & liberty in MinGW/Msys do not fit 
> together?

Not just possible; it's a well known, often stated fact that they are
completely incompatible; (an incompatibility which affects any attempt
to mix MinGW libs with MSYS libs, in any single application).

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX8SZuAAoJEMCtNsY0flo/weAP/i+OwAi1sJGWOawp6uTdRJw9
r6kpO8hGagTd8msm83tTQzCzXXazzcC1ip8PbRdzk8XZL2qJbAaHEjgsRs+yxAUi
8uvwqasgAKCEDE+uV8CzAo2yfBjkMbAq2eGvEnnP0OR4FkPnGYsWf6yPqS9MjBYR
x+RjsttEZoX3NvEYfmBQmE94GEhdzGm+sYZMcKAMbkeG/LoRrAurbJPRAyJUA1bK
j19awJEUT+fyyasWofqyPV0HO5Uz+7eo2J9tIJBUygO9BmqngNVoaVsY/sruFUhs
1lIgZr+vsAXFNFne3lShkHQIYjj3oTYMBCb+jBMBedygaduc9skKaiiKeM+sPXlO
suzgOK1cvs5LHHYaoSHbbs69n5hnaqGgdoNhg0oz4eJ86w2A3CU1X7Muff5Pp2sK
YTUmuiVdk8W2Sq9MoK+sjw1/LuOCLzyP2aLQ0JLFTSUS7rRRhsjAF57fT2hvoF6u
mpnrFG5wWfPACKVV35GskZX7GxiyXZQgy/wMgc/z3yjCcCpDaf50cFfkc98/8o6G
dZtAnEN/RjOZuR7+AEkU8uBIWKLcBsSN4T+vjymZvfrDrRcXYuGBxXGyYRLBhB1t
ctBOGzVP/e0aRsL8BIQ6OhmLFHiqcyKxm9UAoUzw+VL6lvL0DUnf4C/D/GiEm1gO
DbSIa62fHtTT1BeEv17L
=dKrF
-----END PGP SIGNATURE-----

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Alan W. I. <ir...@be...>]

On 2016-10-01 14:15+0200 Jannick wrote:

>              mingw32-g++.exe -o t.exe main.c -lbfd -lintl -liberty -lz

Hi Jannick:

I am just lurking on this list out of general (future) interest and
don't have MinGW-w64/MSYS2 actually available to me yet. Neverthless,
out of curiosity, I checked your first undefined reference,
filename_ncmp with a google search (google is always your friend for
undefined reference issues), and that routine is apparently defined by
the libiberty library.  So I agree you should be using at least the
-liberty flag above (since -liberty should normally translate to
whatever the actual libiberty library name is on MinGW-w64/MSYS2). But
since that flag is obviously not finding the libiberty library, my
guess is you don't have the libiberty development library installed.
Have you searched your MinGW-w64/MSYS2 installation for any reference
to the "iberty" name fragment?

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Alan W. I. <ir...@be...>]

On 2016-10-01 09:09-0700 Alan W. Irwin wrote:

> On 2016-10-01 14:15+0200 Jannick wrote:
>
>>              mingw32-g++.exe -o t.exe main.c -lbfd -lintl -liberty -lz
>
> Hi Jannick:
>
> I am just lurking on this list out of general (future) interest and
> don't have MinGW-w64/MSYS2 actually available to me yet. Neverthless,
> out of curiosity, I checked your first undefined reference,
> filename_ncmp with a google search (google is always your friend for
> undefined reference issues), and that routine is apparently defined by
> the libiberty library.  So I agree you should be using at least the
> -liberty flag above (since -liberty should normally translate to
> whatever the actual libiberty library name is on MinGW-w64/MSYS2). But
> since that flag is obviously not finding the libiberty library, my
> guess is you don't have the libiberty development library installed.
> Have you searched your MinGW-w64/MSYS2 installation for any reference
> to the "iberty" name fragment?

Oops. I am lurking on both the MinGW/MSYS list and the MinGW-w64/MSYS2
mailing lists and incorrectly assumed you were using the latter platform.  But since you are using
the former, please translate everything I said above as follows:

MinGW-w64/MSYS2 ==> MinGW/MSYS.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

Hey Irwin,

> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, October 1, 2016 6:15 PM

> > I am just lurking on this list out of general (future) interest and
> > don't have MinGW-w64/MSYS2 actually available to me yet. Neverthless,
> > out of curiosity, I checked your first undefined reference,
> > filename_ncmp with a google search (google is always your friend for
> > undefined reference issues), and that routine is apparently defined by
> > the libiberty library.  So I agree you should be using at least the
> > -liberty flag above (since -liberty should normally translate to
> > whatever the actual libiberty library name is on MinGW-w64/MSYS2). But
> > since that flag is obviously not finding the libiberty library, my
> > guess is you don't have the libiberty development library installed.

Since liberty.a is not available in the MinGW lib folder, I linked the
version 
in the Msys folder.
 
> > Have you searched your MinGW-w64/MSYS2 installation for any reference
> > to the "iberty" name fragment?

Yep, I did: no result other than ' C:\MinGW\msys\1.0\lib\libiberty.a'.
 
> Oops. I am lurking on both the MinGW/MSYS list and the MinGW-
> w64/MSYS2 mailing lists and incorrectly assumed you were using the latter
> platform.  But since you are using the former, please translate everything
I
> said above as follows:
> 
> MinGW-w64/MSYS2 ==> MinGW/MSYS.

No problem. :) But again: The funny thing here is that while bfd.a is
available in the MinGW
Lib folder, liberty.a is not, which is why I linked the version in the Msys
folder.
Supposedly this version is outdated (pls cf. my other posting to Eli's
response) and
- this is my innocent but really wild guess - liberty.a is missing as a lib
shipped with 
MinGW.

Many thanks,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Zouzou <int...@12...>]

On 01/10/2016 18:38, Jannick wrote:
> No problem. :) But again: The funny thing here is that while bfd.a is
> available in the MinGW
> Lib folder, liberty.a is not, which is why I linked the version in the Msys
> folder.
> Supposedly this version is outdated (pls cf. my other posting to Eli's
> response) and
> - this is my innocent but really wild guess - liberty.a is missing as a lib
> shipped with
> MinGW.

Hey,

Sorry I have not read the whole thread; but regarding this particular 
point, <http://cygwin.com/ml/cygwin/2011-06/msg00149.html> explains why 
one cannot expect bfd & iberty libraries in MinGW packages and why one 
should refrain from using / linking to them.

Hope it's relevant here.

Zouzou

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

Salut Zouzou,

> From: Zouzou [mailto:int...@12...]
> Sent: Saturday, October 1, 2016 7:08 PM
> 
> On 01/10/2016 18:38, Jannick wrote:
> > No problem. :) But again: The funny thing here is that while bfd.a is
> > available in the MinGW Lib folder, liberty.a is not, which is why I
> > linked the version in the Msys folder.
> > Supposedly this version is outdated (pls cf. my other posting to Eli's
> > response) and
> > - this is my innocent but really wild guess - liberty.a is missing as
> > a lib shipped with MinGW.
 
> Sorry I have not read the whole thread; but regarding this particular
point,
> <http://cygwin.com/ml/cygwin/2011-06/msg00149.html> explains why one
> cannot expect bfd & iberty libraries in MinGW packages and why one should
> refrain from using / linking to them.

Thanks, that is interesting.

However, now I am able to run a pure msys compilation to produce a working
executable (thanks to Sergio on this list!). I missed this in the first
place, since I had to additionally load the msys core utils to make that
happen with both the library bfd and liberty residing in the msys lib
folders.

Thus it looks to me that
- msys has consistent libs bfd and liberty to compile on msys level
- liberty.a is missing in the MinGW lib folder
- a mixed compilation approach (msys & MinGW) uses incompatible libs, hence
linking breaks. 

Merci beaucoup,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

> From: Jannick [mailto:thi...@gm...]
> Sent: Saturday, October 1, 2016 7:41 PM

> However, now I am able to run a pure msys compilation to produce a
> working executable (thanks to Sergio on this list!). I missed this in the
first
> place, since I had to additionally load the msys core utils to make that
> happen with both the library bfd and liberty residing in the msys lib
folders.
> 
> Thus it looks to me that
> - msys has consistent libs bfd and liberty to compile on msys level
> - liberty.a is missing in the MinGW lib folder
> - a mixed compilation approach (msys & MinGW) uses incompatible libs,
> hence linking breaks.

Here a way to get the initial main.c (see the initial posting) compiled
purely with MinGW (i.e. without any reference to msys if I am not missing
anything behind the scenes) and a linking a freshly compiled GNU binutils
package (from https://www.gnu.org/software/binutils, v2.27 as of today). In
a msys shell I compiled the package with

	./configure --disable-nls
	make 

where `--disable-nls` avoids linking errors (with intl library involved). (I
am hesitating to run 'make install' after passing '--prefix=C:/MinGW' to
./configure to not overwrite other files and executables). Then linking
with, e.g., 

	mingw32-gcc -o t.exe main.c \
		C:path/to/binutils-2.27/bfd/.libs/libbfd.a\
		C:/path/to/binutils-2.27/libiberty/libiberty.a
		-lz

does the job for main.c here.


I guess it would be great to push that - if possible - thru the MinGW
package in one of the next MinGW releases. But this is certainly up to the
maintainers, of course.

Many thanks,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Eli Z. <el...@gn...>]

> From: "Jannick" <thi...@gm...>
> Date: Sat, 1 Oct 2016 23:28:29 +0200
> 
> Here a way to get the initial main.c (see the initial posting) compiled
> purely with MinGW (i.e. without any reference to msys if I am not missing
> anything behind the scenes) and a linking a freshly compiled GNU binutils
> package (from https://www.gnu.org/software/binutils, v2.27 as of today). In
> a msys shell I compiled the package with
> 
> 	./configure --disable-nls
> 	make 

These two commands need MSYS to run correctly, because otherwise you
won't have Posix-compliant shell, Make, and other utilities needed for
the build.

> (I am hesitating to run 'make install' after passing
> '--prefix=C:/MinGW' to ./configure to not overwrite other files and
> executables).

No need to hesitate: just say

  make install prefix=/some/where/else

to get everything installed in that other place.

> I guess it would be great to push that - if possible - thru the MinGW
> package in one of the next MinGW releases. But this is certainly up to the
> maintainers, of course.

To push what?  addr2line is already included in the Binutils
distribution, so what else is needed?

(I'm not a MinGW maintainer.)

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

> From: Eli Zaretskii [mailto:el...@gn...]
> Sent: Sunday, October 2, 2016 8:58 AM

> > Here a way to get the initial main.c (see the initial posting)
> > compiled purely with MinGW (i.e. without any reference to msys if I am
> > not missing anything behind the scenes) and a linking a freshly
> > compiled GNU binutils package (from
> > https://www.gnu.org/software/binutils, v2.27 as of today). In a msys
> > shell I compiled the package with
> >
> > 	./configure --disable-nls
> > 	make
> 
> These two commands need MSYS to run correctly, because otherwise you
> won't have Posix-compliant shell, Make, and other utilities needed for the
> build.

Fully agree for the first step creating necessary libraries to then compile
main.c with *MinGW*. This is why I did it this way.
 
> > (I am hesitating to run 'make install' after passing
> > '--prefix=C:/MinGW' to ./configure to not overwrite other files and
> > executables).
> 
> No need to hesitate: just say
> 
>   make install prefix=/some/where/else
> 
> to get everything installed in that other place.

Well, I have not checked that due to potentially concurring versions of
libraries shipped with MinGW on one hand and those sitting in the other
folder as you proposed on the other hand. But certainly a good idea to give
it a try. Thanks for this.

> > I guess it would be great to push that - if possible - thru the MinGW
> > package in one of the next MinGW releases. But this is certainly up to
> > the maintainers, of course.
> 
> To push what?  addr2line is already included in the Binutils distribution,
so
> what else is needed?

I cannot find the library (lib)addr2line.a in my MinGW distribution which I
intended this thread to be all about as indicated in its subject and in the
very first posting. Of course, there is addr2line.exe which is a different
story though. Happy to see how to load (lib)addr2line.a, because I could not
find how to do. 

> (I'm not a MinGW maintainer.)

Happy to add here again what appears to be missing in the MinGW
distribution:
So what would be great to have is libbfd.a including its required
dependencies (such as libliberty.a) such that the MinGW compilation of, say,
the sample program main.c in the first posting works.

The workaround using a GNU binutils package newly compiled with msys as
proposed above (overcoming the link error to intl, too) apparently provides
for these requirements, but it would be great to have that in the MinGW
distribution. Given that MinGW does currently ship libbfd.a and bfd.h,
however without sufficient dependencies to link with, it might be an
objective of the MinGW distribution.

I hope that this could clarify. Sorry for having been too sloppy in the
first place. I am wide open for other solutions to link with (lib)bfd.a with
MinGW's linker, of course.

Thanks,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Keith M. <kei...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/10/16 09:53, Jannick wrote:
>> From: Eli Zaretskii [mailto:el...@gn...]
>>> I guess it would be great to push that - if possible - thru
>>> the MinGW package in one of the next MinGW releases. But this
>>> is certainly up to the maintainers, of course.
>> 
>> To push what? addr2line is already included in the Binutils 
>> distribution, so what else is needed?
> 
> I cannot find the library (lib)addr2line.a in my MinGW distribution
> which I intended this thread to be all about as indicated in its
> subject and in the very first posting. Of course, there is
> addr2line.exe which is a different story though. Happy to see how
> to load (lib)addr2line.a, because I could not find how to do.
> 
>> (I'm not a MinGW maintainer.)

I am, and I'm mystified by this request.  Whence would libaddr2line.a
come?  Logically, one might expect it to be provided by binutils,
along with addr2line.exe, but it certainly does not appear in my
binutils build tree, nor can I see any configuration option to create it.

> Happy to add here again what appears to be missing in the MinGW 
> distribution: So what would be great to have is libbfd.a

Already provided, within the mingw32-binutils-dev package.

> including its required dependencies (such as libliberty.a)

AFAIK, there is no such entity as libliberty.a; I guess you mean
libiberty.a, which is currently provided as a free-standing package:
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version5/gcc-5.3.0-2/libiberty-gcc-5.3.0-2-mingw32-dev.tar.xz/download

> The workaround using a GNU binutils package newly compiled with
> msys as proposed above (overcoming the link error to intl, too)
> apparently provides for these requirements, but it would be great
> to have that in the MinGW distribution. Given that MinGW does
> currently ship libbfd.a and bfd.h, however without sufficient
> dependencies to link with, it might be an objective of the MinGW
> distribution.

Downloading, and manually unpacking, the aforementioned package would
probably have offered a quicker solution.

I agree that MinGW.org could distribute libiberty.a rather more
transparently than it does at present: likely it would be sensible to
include it in the same mingw32-binutils-dev package as libbfd.a; that it
doesn't appear there at present is an oversight, (caused by the need to
specify an additional configuration option to get it installed in the
staging tree -- it isn't included in a default installation -- and
compounded by confusion over which package actually owns it -- it
is built as a duplicate component by both GCC and binutils).

As to distributing a libaddr2line.a ... I've no idea how I would build
that, nor any clue as to what payload it should deliver.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX8Ry4AAoJEMCtNsY0flo/f5wQAKKFJMD1DerIc6qX5lfID0wI
rdRgk0e4rK64nTeywbyyGrJpGoOK23o373b1niKhYb/ZwtVvBYupuVhgOL61yynP
Jrv/EuzIjQRDrJCsOWaKVHj+MBhuO7J9Oge3a+nBW3xVEvjP0CDo5xkPQC2pCt2c
lU6GuZft+yp2qCDc60d2ARcqLqmqj/Y0ggeN3CDJyBrL8JCQl4u0FxrwGAnGD8xR
S6qfXVt2PsbVTmbz/twh2WXPnqQ3VxKFS8Z1k2iKZBkWYRAeZsIoGiSLcbbeL62R
gWx9CcruxZvqoCplpFQhnErJFbx8PSCYTqW9lEdG8B5pvDC1fM5lSX3N1feMTkwF
mDKYv8Al+Byok3sPWTTo6d6/uygMlx97YaSYykFC/fI1K1pEsTd4EupN3lhQRp2M
un+AI0HINRJ+7jsI7IGVDsX1SK1ELPKHZsvgRzdr43bLQOISWgFcwB2hl7HpGjHu
eM2mNWxnHBx9WMAKNCpev2SheM8m2ad5ORNySD5bNEw3TMyqHyQjDIVB8XMUuOtc
WOGYAwseU0NG6OcMPVSLRnLLK9jBGXPsFuyw5FZaEB59TQpRJAO6A7c/t967g68M
/o5ZTltvSljUfOgXJlSugtqZchONVxHCAHmMDfHO+nt05itd1VYVbn1Oj4hw/cJr
fSXEnRN8016bJm+MZFoB
=FiG1
-----END PGP SIGNATURE-----

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

On Oct 02, 2016 at 04:42 PM, Keith Marshall wrote:

> On 02/10/16 09:53, Jannick wrote:
> > So what would be great to have is libbfd.a
> 
> Already provided, within the mingw32-binutils-dev package.
> 
> > including its required dependencies (such as libliberty.a)
> 
> AFAIK, there is no such entity as libliberty.a; I guess you mean
libiberty.a,
> which is currently provided as a free-standing package:
>
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version5/gcc-5.3
.0-2/libiberty-gcc-5.3.0-2-mingw32-dev.tar.xz/download
> 
> > The workaround using a GNU binutils package newly compiled with msys
> > as proposed above (overcoming the link error to intl, too) apparently
> > provides for these requirements, but it would be great to have that in
> > the MinGW distribution. Given that MinGW does currently ship libbfd.a
> > and bfd.h, however without sufficient dependencies to link with, it
> > might be an objective of the MinGW distribution.
> 
> Downloading, and manually unpacking, the aforementioned package would
> probably have offered a quicker solution.

Thanks - agree. However, this package comes along with the implied
dependency to libintl-8.dll which, in general, I wanted to avoid. Is there a
version of libiberty.a (I got it now I believe) out there which is
independent of the library intl? This is why I suppressed this dependency
when I compiled the full GNU binutil package.

Separately, what would be the package spec to have 'mingw-get' download and
install libiberty.a/.h from sfn to the MinGW folder? 
BTW: 'mingw-get list' breaks here exactly when prompting the beginning of
the information of 'mingw32-libatomic'. I tried to call that to check if
libiberty is in mingw-get's list, in principle. 
 
> I agree that MinGW.org could distribute libiberty.a rather more
transparently
> than it does at present: likely it would be sensible to include it in the
same
> mingw32-binutils-dev package as libbfd.a; that it doesn't appear there at
> present is an oversight, (caused by the need to specify an additional
> configuration option to get it installed in the staging tree -- it isn't
included in
> a default installation -- and compounded by confusion over which package
> actually owns it -- it is built as a duplicate component by both GCC and
> binutils).
> 
> As to distributing a libaddr2line.a ... I've no idea how I would build
that, nor
> any clue as to what payload it should deliver.

Certainly it would be enough to have all dependency libraries of libbfd.a in
the MinGW distribution to compile a stand-alone executable without any
additional dll dependency induced by bfd's direct or indirect dependencies
(e.g., libintl-8.dll).

Sorry for the noise about all that which effectively goes back to the
libiberty.a issue. Thanks for your time and patience with me, since I am
still quite a novice to c programming and to using MinGW,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Keith M. <kei...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/10/16 19:54, Jannick wrote:
>> Downloading, and manually unpacking, the aforementioned package 
>> would probably have offered a quicker solution.
> 
> Thanks - agree. However, this package comes along with the implied 
> dependency to libintl-8.dll which, in general, I wanted to avoid.

You'll need to provide a SSCCE, to help me understand where that
dependency arises; I'm not seeing it in my build trees, for either
the distributed libbfd.a or libiberty.a, (when inspected using
"objdump -x ... | grep -i dll" -- not that I'd really expect it
to show up, within a static library, until the linker finds a
symbol dependency which needs the DLL in question).

> Separately, what would be the package spec to have 'mingw-get' 
> download and install libiberty.a/.h from sfn to the MinGW folder?

There isn't one.  "Download and manually unpack" means just that:
download the package, from the provided reference link, then run
"tar xf ..." to unpack it into the root of your MinGW tree.

> BTW: 'mingw-get list' breaks here exactly when prompting the 
> beginning of the information of 'mingw32-libatomic'. I tried to
> call that to check if libiberty is in mingw-get's list, in
> principle.

Thanks for pointing this out; indeed, mingw-get seems to choke on
empty paragraph elements, inadvertently left within the descriptions
of mingw32-libatomic, and later mingw32-libgomp and mingw32-libssp.
That should now be fixed, if you run "mingw-get update" first.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX8tiOAAoJEMCtNsY0flo/A40P/Rw8bx4E/GngM54W0uImeNWn
cjpP6UwWR27KXUy5AwFqL2JndxcF9/Hcm0JUrS7RrQuAvPN8jOKu9IlUwFS+1YVg
VbjKk1xtcEq7QPpefv/f+YDa8X0sw0t1MX4Q/JgI8GWrnN9VTSV498mQzKkm6nC+
Eu6I8pNwiE1j207p720lmsB3r29CKqaAvMyg3VwFXFFWIzkh6ECd30U2wrb5h9Yp
lCK5rJczC0nkx95tccaZa4xjN3GYrDvxUep4yw6j4B8Y7qm7uWbOvPuVK5deDggP
NjIE6T5FKTb8k5UEof91s8sFuKqx8/B1AQAutnwjjj15iOU5pZd4I5n8HymeD/0C
H5vokBwXcamcjiYvVDkVvZhbEUONaD4Pv8MZpfD0Y5mUMUrsbHjdIiBTYISCVqNb
oIsDgtIPq+FAmQU+fNugFn6lyVszYGxxc1w9WDTNMU/oKwSabgWj50Dhc+Hoxhth
Pmtx7qcyZvM4dDZvQLvHIi+ZUP6yrLZALGpN63ctQw4wIYc4/k6MJzKfdK4UskhU
Am7ScOF6eR2FoFYqc+zbVCNePMzotOY91WrsPnKOIFFCLNYf39xC7GV3tKkXhHl3
PAjQaGg42sASn/JqolPARYU1rnTvVFt0nIDsT/V5pbdv6zVArXFvtPx8YMUTtqOz
EbfXE5yjPR9CupqUp84J
=PYY3
-----END PGP SIGNATURE-----

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Eli Z. <el...@gn...>]

> From: Keith Marshall <kei...@us...>
> Date: Mon, 3 Oct 2016 23:15:42 +0100
> 
> > Thanks - agree. However, this package comes along with the implied 
> > dependency to libintl-8.dll which, in general, I wanted to avoid.
> 
> You'll need to provide a SSCCE, to help me understand where that
> dependency arises; I'm not seeing it in my build trees, for either
> the distributed libbfd.a or libiberty.a, (when inspected using
> "objdump -x ... | grep -i dll" -- not that I'd really expect it
> to show up, within a static library, until the linker finds a
> symbol dependency which needs the DLL in question).

If you run "nm -A" on libbfd.a, don't you see the likes of
_libintl_dgettext and _libintl_snprintf, all of them "undefined"
(i.e. with the "U" marker)?  If you don't, perhaps your libbfd comes
from a different package than Jannick's (and mine).

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

On Oct 04, 2016 at 08:24 AM, Eli Zaretskii wrote:
> 
> > From: Keith Marshall <kei...@us...>
> > Date: Mon, 3 Oct 2016 23:15:42 +0100
> >
> > > Thanks - agree. However, this package comes along with the implied
> > > dependency to libintl-8.dll which, in general, I wanted to avoid.
> >
> > You'll need to provide a SSCCE, to help me understand where that
> > dependency arises; I'm not seeing it in my build trees, for either the
> > distributed libbfd.a or libiberty.a, (when inspected using "objdump -x
> > ... | grep -i dll" -- not that I'd really expect it to show up, within
> > a static library, until the linker finds a symbol dependency which
> > needs the DLL in question).

Sure. Compile main.c below with

	mingw32-gcc main.c -o t.exe -lbfd -liberty -lintl -lz

to see that t.exe is dependent on libintl-8.dll.

<main.c>
#define PACKAGE "your-program-name"
#define PACKAGE_VERSION "1.2.3"

#include <stdio.h>
#include <bfd.h>

int main(int argc, char** argv)
{
    bfd_init();

    char* fn=argv[0];
    printf("exe: '%s'\n", fn);

    bfd* file = bfd_openr(fn, 0);

    if (!file)
        return 1;

    if (bfd_check_format(file, bfd_object))
        printf("object file\n");
    else
        printf("not object file\n");

    bfd_close(file);

    return 0;
}
</main.c>
 

> If you run "nm -A" on libbfd.a, don't you see the likes of
_libintl_dgettext and
> _libintl_snprintf, all of them "undefined"
> (i.e. with the "U" marker)?  If you don't, perhaps your libbfd comes from
a
> different package than Jannick's (and mine).

Thanks, Eli. I do see them as well. The date stamp of libbfd.a here is Sep
9, 2015, if this is of any help. 

Regards,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

On Oct 04, 2016 at 09:20 AM, Jannick wrote:
> > > From: Keith Marshall <kei...@us...>
> > > Date: Mon, 3 Oct 2016 23:15:42 +0100
> > >
> > > > Thanks - agree. However, this package comes along with the implied
> > > > dependency to libintl-8.dll which, in general, I wanted to avoid.
> > >
> > > You'll need to provide a SSCCE, to help me understand where that
> > > dependency arises; I'm not seeing it in my build trees, for either
> > > the distributed libbfd.a or libiberty.a, (when inspected using
> > > "objdump -x ... | grep -i dll" -- not that I'd really expect it to
> > > show up, within a static library, until the linker finds a symbol
> > > dependency which needs the DLL in question).
> 
> Sure. Compile main.c below with
> 
> 	mingw32-gcc main.c -o t.exe -lbfd -liberty -lintl -lz
> 
> to see that t.exe is dependent on libintl-8.dll.

I should refine my objective which is why to exclude the intl dependency: My
intention is to produce a stand-alone executable, i.e. an executable with
references to pure Windows dlls only which are available on - hopefully -
every Windows machine; I guess this means '-static' in c lingo. 

Now, after saying 'set PATH=' I discovered that t.exe (compiled with '
mingw32-gcc main.c -o t.exe -lbfd -liberty -lintl -lz ') depends on another
non-Windows dll (corresponding to libiconv.a). I amended this by linking
with '-static' and including '-liconv', i.e.

	mingw32-gcc.exe main.c -o t.exe -static -lbfd -liberty -lintl
-liconv -lz

which produces a 'stand-alone executable'.

BTW: Is there an easy standard *one-step* approach to determine the complete
dependency graph of (non-Windows) libraries to be linked with given the
'root libraries' which are linked in the first place? In the example
above/below that would mean that the libraries 'libiberty.a', 'libintl.a',
'libiconv.a' and 'libz.a' are spit out somehow given the root library
'libbfd.a'.

As a side remark, compiling the GNU binutils package from scratch with an
initial 

	./configure --disable-nls

I could turn off the dependency on intl.

> <main.c>
> #define PACKAGE "your-program-name"
> #define PACKAGE_VERSION "1.2.3"
> 
> #include <stdio.h>
> #include <bfd.h>
> 
> int main(int argc, char** argv)
> {
>     bfd_init();
> 
>     char* fn=argv[0];
>     printf("exe: '%s'\n", fn);
> 
>     bfd* file = bfd_openr(fn, 0);
> 
>     if (!file)
>         return 1;
> 
>     if (bfd_check_format(file, bfd_object))
>         printf("object file\n");
>     else
>         printf("not object file\n");
> 
>     bfd_close(file);
> 
>     return 0;
> }
> </main.c>

Thanks,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Eli Z. <el...@gn...>]

> From: "Jannick" <thi...@gm...>
> Date: Tue, 4 Oct 2016 11:15:43 +0200
> 
> BTW: Is there an easy standard *one-step* approach to determine the complete
> dependency graph of (non-Windows) libraries to be linked with given the
> 'root libraries' which are linked in the first place? In the example
> above/below that would mean that the libraries 'libiberty.a', 'libintl.a',
> 'libiconv.a' and 'libz.a' are spit out somehow given the root library
> 'libbfd.a'.

Get the dependency walker:

  http://www.dependencywalker.com/

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Keith M. <kei...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/10/16 07:24, Eli Zaretskii wrote:
> If you run "nm -A" on libbfd.a, don't you see the likes of 
> _libintl_dgettext and _libintl_snprintf, all of them "undefined" 
> (i.e. with the "U" marker)?

Indeed, yes; (thanks for reminding me that I should have thought to
check that).

However, in the original gettext-0.18.3.2-2-mingw32-dev archive, I see
both libintl.a and libintl.dll.a, (the former a static library); using
that static variant will resolve those symbols without introducing any
dependency on libintl-8.dll at link time.  I consider it advantageous
to the majority of end users, that our distributed packages offer i18n
support where practicable, particularly so when the DLL dependency may
be avoided by the simple expedient of static linking with libintl.a,
(and maybe stripping the resultant EXE or DLL, since libintl.a appears
to include debugging info).

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX85drAAoJEMCtNsY0flo/oZYQAJArgcM9s022Cvlkfw6URrU1
SDECT8rX3YV9lVzO5NhxlIZhM5DF72UBxOBQMIWJMy/RLb8JOTn8vvvyaHsmWPbF
KQX/rNVVUUn0QAr6VWAqI5a0uo/HNNX2L7UDpTphLZ7iDgN15nl/s7hnwuw7nehu
rQjlPqvNjU+MuZSYsp2wlEeRl1HFz8m56ad1i7qXG8QqWZKZuuuV5d0DgX+uw+Aw
DFmfVaD2QOqKO9OVzoUMWsCYZEPmSXbfyPxyt/Pjd+UdOrZpiCvJkUVDLMiPW9tA
7DcB9Mk1nSry24bOCsjSX3IOx7We5vBrxnGAiYSZzcNrt6i6lXH7SD9TiytwI/VG
RZOBMNxEfmWVboPfbWevgijfpMKGGoeKeln8BUe93RMomJcb4nqFtD/idrwJbo/Y
24w2gUg4zgEN1V40eC5DotWe6KjRy/etVljY539p8wXu0MxW/baj3M3cla/FKP1I
R2CtFXlMRCrYlL1iXBcYWRBsmGpyKQkTt4zNoOu08RsBBFbbTWr2EW8y39jYp9NM
eZlj8ImaDo4LjNNErFCc7OhdVlfszV08oYz/7WSm56Gcl6lAJR9zQPAnK2GyYXsF
+XjNFcJFkATdGKuT9mLvicl7yGlzooS9BnHlVVQQ392TQai0WGm0wCJYrmQtunJP
uJhuoSU05n3ECFeSlFJJ
=QD74
-----END PGP SIGNATURE-----

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

On Oct 04, 2016 at 12:15 AM, Keith Marshall wrote:
> On 02/10/16 19:54, Jannick wrote:

> > BTW: 'mingw-get list' breaks here exactly when prompting the beginning
> > of the information of 'mingw32-libatomic'. I tried to call that to
> > check if libiberty is in mingw-get's list, in principle.
> 
> Thanks for pointing this out; indeed, mingw-get seems to choke on empty
> paragraph elements, inadvertently left within the descriptions of mingw32-
> libatomic, and later mingw32-libgomp and mingw32-libssp.
> That should now be fixed, if you run "mingw-get update" first.

Great - that works well now. Many thanks.

Regards,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Keith M. <kei...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/10/16 22:47, Jannick wrote:
>> Get the dependency walker:
>> 
>> http://www.dependencywalker.com/
> 
> Indeed, this is very interesting. I will try to use the dependency 
> walker to have an automated approach to determine all dependencies 
> (other than system dll's) of an executable.

Another option is the "objdump -x ... | grep -i 'dll name'" command I
suggested in and earlier post.  Not only is it quicker than waiting for
the dependency walker to start up, but it can also be used in a cross
compiling environment on a non-Windows host; (indeed, the example I gave
earlier was actually run on a LinuxMint Debian Edition host).  You may
specify any .exe or .dll argument, to see its DLL dependencies.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX9Xi5AAoJEMCtNsY0flo/2TYP/3pQXLApv8wld8MuccF6ahez
bv4JMUrCw5mZDnBv0C8/BLvTJ+kW+vSBkzYWIQeP/Me+UZRl/2KIxppn0afBUrmw
NdGkmhlbOvOOG7lfe7oQsw4SA0eTKWtaMmCu7eDqh5Yq9qbRbVTJr7RsEB7GfGB2
gGTmdFQyGaYZ/w4xefq2BZ3iBIXrZtiD6feKN9+7RlvDsozbs1lAWwNxllzPG9mL
AXCvrhOEPFrzFNkTaSRsmkDpTd9h2Kf6M/Luhs3amkNDvERcLCZvNf4aYVtSRUYe
XuQ3JHZ79lTUTmxMllQPZTbLd8MUFRF3hCbx6GqTtDO+1PeeUZTucHkemFb9YDap
3LB7ihAiIaOa5DrWqC618Rgd+zGB3ryeittJ/y4RwHzVO+QNl2up9O6WfEHY4FfL
Pt1l3/tX92VEvesu8jSYmY7G/N5AWUgBJrsyAZquSr4EKGbLXYArymBjtGYgpkK7
elu6es3p8iHdfi8hw9IcPqyhlS3Q7MBp/HIWy2uitlRjKa3rGRkeIY1eWn6nEz9V
8zWoBMTN+fCuquH2c5fc6DKgl/l1mvycS7mKFIRxGcP75eom6JAGH5EDF+NBEFyb
CrbFP1sT1gyZPkuIwdbeEBQuUFNzAOsCwbLOnATQr1LS2Uyi0YWRRRnvL3Er/GQM
q4MWlwgP1HD2w7o36tpZ
=O2+k
-----END PGP SIGNATURE-----

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

On Oct 06, 2016 at 12:03 AM, Keith Marshall wrote:
> On 05/10/16 22:47, Jannick wrote:
> >> Get the dependency walker:
> >>
> >> http://www.dependencywalker.com/
> >
> > Indeed, this is very interesting. I will try to use the dependency
> > walker to have an automated approach to determine all dependencies
> > (other than system dll's) of an executable.
> 
> Another option is the "objdump -x ... | grep -i 'dll name'" command I
> suggested in and earlier post.  Not only is it quicker than waiting for
the
> dependency walker to start up, but it can also be used in a cross
compiling
> environment on a non-Windows host; (indeed, the example I gave earlier
> was actually run on a LinuxMint Debian Edition host).  You may specify any
> .exe or .dll argument, to see its DLL dependencies.

Thanks, I have seen your approach you mentioned in the other posting which
is easy, efficient and pretty much straight forward. However, if I am not
mistaken, it can determine the direct dependencies, only. 

After reading a bit about the dependency walker the executable is required
to be run (i.e. it is to be run by the dependency walker's profiler) to
effectively determine all dll's called by the functions of that very run. On
the other hand, your approach could be recursively applied to determine the
complete directed call graph. That is fine in our example which is simple
enough to have a depth of two or three only. But this manual approach does
not appear to be appropriate, since tedious, for more complex projects I
guess.

The cross compiling argument makes your approach even stronger, however, -
as a bare c novice - I stick to MinGW(indows) and try to not get confused by
other systems (for now).

Best regards,
J.

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Keith M. <kei...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/10/16 13:15, Jannick wrote:
> with
> 
> mingw32-g++.exe -o t.exe main.c -lbfd -lintl -liberty -lz
> 
> should be fine, in principle, i.e. MinGW's bfd appears to depend
> on the libraries intl, (l)iberty and z, at least. For MinGW
> compilation gcc needs -LC:\MinGW\msys\1.0\lib for linking.

Sigh.  How many bazillion times must we repeat this?  You absolutely
MUST NOT ever attempt to link ANYTHING in this lib directory into any
build with the MinGW compiler; they are intended exclusively for use
by developers of the MSYS platform itself, using the MSYS special
version of GCC, and are incompatible with MinGW's GCC.

> But still, the MinGW compiler is complaining:

Hardly surprising, since you are trying to force it to use libraries
which are not compatible with it.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX8RLfAAoJEMCtNsY0flo/4OAP/3T523VN/2FMFrvABK4PrdTi
CnfUypP78PW4DAA4I4gPNGDmc+ve1OGsPQTDAYSEwLgjpOXlay2NfX47z4INyab7
Te3VyMUp8B8EPRnJ9NZfUekgQVicd2xxfm9sY0CwhjpymyV0Kg/grxdUuLXkuh1P
v2AgEJwm36QdHtuIsTycfMcmBxYDZ6VhGBtKIhxesEHahrM063t/gkoywTksnrb7
dDxnU3JvI94aDVddZx/OBZ0vh8M/NzJ3FZGwoighDifrWIV/WSbM5Hl1WU1MkDQp
Ss4rPh2n0GiHJjK+xrpNWBpqNYhjThsSouOz9u0iLm2MQPofh1cFeJa/hDTmTJjB
FjwAQ4QtfbHbQqVdUGe+3gY0fl6n3KOIuRpU8gIf8x+mdKeRtg97ZdwTPXh2aOwP
uynIWh5tTUx/vvuYvLV/o6UESFr65+5xocCh0IA4+IkImumPM4IMP0RCTH07izOn
1YEM/MUKsrp936raBDCScrz2jr3tZC1REyLhqMbrgMlg+Ujlw4DBM1j9U5Lev5ny
bUEVCzA0jAH9YRfl74HaWRzVngns42juoaaA0c3ACAMJQeIu701qACurXE0qqW2y
MWwmzfQld1RX0lUusKkHzim4KZzCnCOjQkOqtITMNHlW2HIAgPD4yNpzxOR47Hsr
OTZgV23gwofcMTZjoW5C
=J95Q
-----END PGP SIGNATURE-----

Re: [Mingw-users] libaddr2line.a: dependencies of libbfd.a?

[Jannick <thi...@gm...>]

Hey Eli,

On Oct 04, 2016 at 12:00 PM, Eli Zaretskii wrote:
> 
> > From: "Jannick" <thi...@gm...>
> > Date: Tue, 4 Oct 2016 11:15:43 +0200
> >
> > BTW: Is there an easy standard *one-step* approach to determine the
> > complete dependency graph of (non-Windows) libraries to be linked with
> > given the 'root libraries' which are linked in the first place? In the
> > example above/below that would mean that the libraries 'libiberty.a',
> > 'libintl.a', 'libiconv.a' and 'libz.a' are spit out somehow given the
> > root library 'libbfd.a'.
> 
> Get the dependency walker:
> 
>   http://www.dependencywalker.com/

Indeed, this is very interesting. I will try to use the dependency walker to
have an automated approach to determine all dependencies (other than system
dll's) of an executable.

Thanks,
J.