Discussion:
[Mingw-users] undefined reference with ___mingw_vfprintf
JC
2009-12-31 13:29:42 UTC
Permalink
Hello,

I have a problem an undefined reference with ___mingw_vfprintf. Do somebody knows where it could come from please ? Here are my compilation log :

-------------- Build: Debug in jkt2010 ---------------
Linking console executable: bin\Debug\jkt2010.exe
Libs\agar-1.3.4-recompile\lib/libag_gui_static.a(file_dlg.o): In function `fprintf':
C:/MinGW/include/stdio.h:246: undefined reference to `___mingw_vfprintf'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 2 seconds)
1 errors, 0 warnings


Best regards
JonY
2009-12-31 13:59:20 UTC
Permalink
Post by JC
Hello,
-------------- Build: Debug in jkt2010 ---------------
Linking console executable: bin\Debug\jkt2010.exe
C:/MinGW/include/stdio.h:246: undefined reference to `___mingw_vfprintf'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 2 seconds)
1 errors, 0 warnings
Best regards
Hi,

try adding libmingwex.a to your link command.
Keith Marshall
2009-12-31 14:57:34 UTC
Permalink
Post by JonY
try adding libmingwex.a to your link command.
He shouldn't need to; it should be specified automatically, if he is
using gcc or g++ correctly for linking.

I don't mean to denigrate your efforts to help, JonY, but without a
proper understanding of *why* MinGW's enhanced printf() subsystem is
being called, IMHO simply saying "add libmingwex.a" is poor advice
indeed, (and FWIW, it was I who actually wrote MinGW's enhanced
printf() subsystem).
--
Regards,
Keith.
JC
2009-12-31 15:38:59 UTC
Permalink
Ok, I thank this would be enough information for an undefined reference problem.

I am a beginner with Code Blocks and with MinGW, before I worked with MSVC...

I launch the compilation with Code Blocks 8.02, and I use mingw32-g++.exe to compile. I don't know how to view the link command generated by code blocks.

The ___mingw_vfprintf unresolved appears when I compile my project with the static librairie Agar (1.3.4 compiled by me for mingw). If I change juste the library of Agar to take the 1.3.3 compiled by the Agar team for mingw I don't have this error.
 
Like you proposed, I have tried to had libmingwex to my link settings but I ever have the same unresolved reference. I think it's the Agar 1.3.4 library compiled by me wich needs stdio.h but I don't know why.
 
I looked for "_mingw.h", this string doesn't appear in my project and also doesn't appear in the agar project.
 a+
J-C




________________________________
De : Keith Marshall <***@users.sourceforge.net>
À : mingw-***@lists.sourceforge.net
Envoyé le : Jeu 31 Décembre 2009, 15 h 57 min 34 s
Objet : Re: [Mingw-users] undefined reference with ___mingw_vfprintf
Post by JonY
try adding libmingwex.a to your link command.
He shouldn't need to; it should be specified automatically, if he is
using gcc or g++ correctly for linking.

I don't mean to denigrate your efforts to help, JonY, but without a
proper understanding of *why* MinGW's enhanced printf() subsystem is
being called, IMHO simply saying "add libmingwex.a" is poor advice
indeed, (and FWIW, it was I who actually wrote MinGW's enhanced
printf() subsystem).
--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
JC
2009-12-31 16:20:31 UTC
Permalink
I found in the Agar source code (the library wich I use) the file "file_dlg.c" uses the fprintf function from stdio.h. So it seems it's normal to add the link dependancy "libmingwex". Isn't it ? But when I add this link dependancy I still have the same error.




________________________________
De : JC <***@yahoo.fr>
À : MinGW Users List <mingw-***@lists.sourceforge.net>
Envoyé le : Jeu 31 Décembre 2009, 16 h 38 min 59 s
Objet : [Mingw-users] Re : undefined reference with ___mingw_vfprintf


Ok, I thank this would be enough information for an undefined reference problem.

I am a beginner with Code Blocks and with MinGW, before I worked with MSVC...

I launch the compilation with Code Blocks 8.02, and I use mingw32-g++.exe to compile. I don't know how to view the link command generated by code blocks.

The ___mingw_vfprintf unresolved appears when I compile my project with the static librairie Agar (1.3.4 compiled by me for mingw). If I change juste the library of Agar to take the 1.3.3 compiled by the Agar team for mingw I don't have this error.
 
Like you proposed, I have tried to had libmingwex to my link settings but I ever have the same unresolved reference. I think it's the Agar 1.3.4 library compiled by me wich needs stdio.h but I don't know why.
 
I looked for "_mingw.h", this string doesn't appear in my project and also doesn't appear in the agar project.
 a+
J-C




________________________________
De : Keith Marshall <***@users.sourceforge.net>
À : mingw-***@lists.sourceforge.net
Envoyé le : Jeu 31 Décembre 2009, 15 h 57 min 34 s
Objet : Re: [Mingw-users] undefined reference with ___mingw_vfprintf
Post by JonY
try adding libmingwex.a to your link command.
He shouldn't need to; it should be specified automatically, if he is
using gcc or g++ correctly for linking.

I don't mean to denigrate your efforts to help, JonY, but without a
proper understanding of *why* MinGW's enhanced printf() subsystem is
being called, IMHO simply saying "add libmingwex.a" is poor advice
indeed, (and FWIW, it was I who actually wrote MinGW's enhanced
printf() subsystem).
--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Keith Marshall
2009-12-31 16:31:53 UTC
Permalink
Post by JC
I am a beginner with Code Blocks and with MinGW, before I worked with MSVC...
That's okay; we were all be beginners once :-)
Post by JC
I launch the compilation with Code Blocks 8.02, and I use
mingw32-g++.exe to compile. I don't know how to view the link
command generated by code blocks.
I can't help you with that, because I don't use an IDE. Is the
command not shown, just before the error messages it produces?
Post by JC
The ___mingw_vfprintf unresolved appears when I compile my project
with the static librairie Agar (1.3.4 compiled by me for mingw).
I guess their build system specifies compilation standards which
would activate MinGW's enhanced printf() subsystem; since you have a
version of mingwrt which supports this, your build of their code
implicitly acquires that dependency.
Post by JC
If I change juste the library of Agar to take the 1.3.3 compiled
by the Agar team for mingw I don't have this error.
Perhaps they built that against an earlier version of mingwrt, which
didn't have the enhanced printf() support, (or they took precautions
to disable it, but then why didn't they incorporate such precautions
into their published build system)?
Post by JC
Like you proposed, I have tried to had libmingwex to my link
settings but I ever have the same unresolved reference. I think
it's the Agar 1.3.4 library compiled by me wich needs stdio.h but
I don't know why.
Most projects, (those which read and write file streams), require
stdio.h; it's a standard system header, provided by MinGW in mingwrt.
From mingwrt-3.15 onward, stdio.h has included conditional defines
to activate the enhanced printf() subsystem, but not by default; it
is only under specific circumstances as described in...
Post by JC
I looked for "_mingw.h", this string doesn't appear in my project
and also doesn't appear in the agar project.
...this system *header* file; I wouldn't expect your project, or any
other, to refer to it directly, (indeed it would be wrong if it did),
but it is implicitly included automatically by every MinGW compile.

Your issue isn't associated with stdio.h per se; it is why the
standard set of system libraries, with libmingwex.a among them, are
not being included in the linking phase of your project build. You
shouldn't need to add any of these libraries explicitly; they should
all be specified automatically, by gcc or g++ when they are invoked
to link the executable; if not, then there is something wrong with
your project build system. To help you resolve that, you should
either remove the IDE from the equation, and learn how to use the
compiler tools directly, or ask for advice on a Code::Blocks mailing
list or forum.
--
Regards,
Keith.
JonY
2009-12-31 17:30:59 UTC
Permalink
Post by Keith Marshall
Post by JonY
try adding libmingwex.a to your link command.
He shouldn't need to; it should be specified automatically, if he is
using gcc or g++ correctly for linking.
I don't mean to denigrate your efforts to help, JonY, but without a
proper understanding of *why* MinGW's enhanced printf() subsystem is
being called, IMHO simply saying "add libmingwex.a" is poor advice
indeed, (and FWIW, it was I who actually wrote MinGW's enhanced
printf() subsystem).
Ok,

I thought he was using msvc "cl" to compile and link, which needs to be
told to use libmingwex.a.

Apparently, this is not the case.
Keith Marshall
2009-12-31 18:29:38 UTC
Permalink
Post by JonY
I thought he was using msvc "cl" to compile and link, which needs
to be told to use libmingwex.a.
It would, IF the dependency on MinGW's enhanced printf() subsystem is
REALLY desired. When building a library intended for use with other
compilers than MinGW, it may be a rash choice to introduce that
dependency; better IMO, to understand why the dependency arises in
the first place, and then make an informed choice on whether to keep
it, or to eliminate it.
Post by JonY
Apparently, this is not the case.
C:/MinGW/include/stdio.h:246: undefined reference to
`___mingw_vfprintf'
collect2: ld returned 1 exit status
The use of collect2 suggests a GNU tool chain, (and the reference in
question shows us that some compilation unit in the project was
built with compile time flags to explicitly map fprintf() to
__mingw_fprintf(), rather than to the default __msvcrt_fprintf()).
--
Regards,
Keith.
JC
2010-01-01 13:44:13 UTC
Permalink
Here is the link command line generated by my IDE (CodeBlocks) followed by the result of the command line. I wish it can help, I don't see anything strange for me.

-------------- Build: Debug in jkt2010_CodeBlocks ---------------
mingw32-g++.exe -LLibs\SDL-1.2.14-MinGW\lib -LLibs\agar-1.3.4-recompile\lib -LLibs\freetype-2.3.5-1-bin\lib -LLibs\fmodapi375win\api\lib -LLibs\Pre-built.2\lib -LLibs\SDL_image-1.2.10\lib -LLibs\SDL_net-1.2.7\lib  -o bin\Debug\jkt2010.exe obj\Debug\Libs\tinyxml_2_5_2\tinystr.o obj\Debug\Libs\tinyxml_2_5_2\tinyxml.o obj\Debug\Libs\tinyxml_2_5_2\tinyxmlerror.o obj\Debug\Libs\tinyxml_2_5_2\tinyxmlparser.o obj\Debug\Menu\Dlg.o obj\Debug\Menu\DlgBoite.o obj\Debug\Menu\MAide.o obj\Debug\Menu\MAudio.o obj\Debug\Menu\MAudioDrivers.o obj\Debug\Menu\MAudioDriversDriver.o obj\Debug\Menu\MAudioOutput.o obj\Debug\Menu\MAudioRecord.o obj\Debug\Menu\MCommandes.o obj\Debug\Menu\MConfiguration.o obj\Debug\Menu\MDebug.o obj\Debug\Menu\MDisplay.o obj\Debug\Menu\MDisplaySize.o obj\Debug\Menu\MMenuPrinc.o obj\Debug\Menu\MMenuPrinc2.o obj\Debug\Menu\MMode.o obj\Debug\Menu\MMultijoueur.o obj\Debug\Menu\MMultijoueurClientInfo.o obj\Debug\Menu\MMultijoueurClientPing.o
obj\Debug\Menu\MMultijoueurServeur.o obj\Debug\Menu\MMultijoueurServeurLancePartie.o obj\Debug\Menu\MOpenASE.o obj\Debug\Menu\MOpenMAP.o obj\Debug\Menu\MOpenScene.o obj\Debug\Menu\MReseau.o obj\Debug\Menu\Menu.o obj\Debug\Menu\Portail.o obj\Debug\src\DeleteWithGame.o obj\Debug\src\centralisateur\Centralisateur.o obj\Debug\src\centralisateur\CentralisateurState.o obj\Debug\src\centralisateur\UdpConnector.o obj\Debug\src\centralisateur\UdpController.o obj\Debug\src\centralisateur\data\Data.o obj\Debug\src\centralisateur\data\ListData.o obj\Debug\src\centralisateur\data\SignalementData.o obj\Debug\src\exception\JktException.o obj\Debug\src\exception\centralisateur\BindingUdpException.o obj\Debug\src\exception\centralisateur\CentralisateurException.o obj\Debug\src\exception\centralisateur\OpenUdpSocketException.o obj\Debug\src\ifstreamWork.o obj\Debug\src\main\Cfg.o obj\Debug\src\main\Clavier.o obj\Debug\src\main\Fabrique.o obj\Debug\src\main\Focus.o
obj\Debug\src\main\Game.o obj\Debug\src\main\JKT.o obj\Debug\src\main\Laser.o obj\Debug\src\main\Photo.o obj\Debug\src\main\Player.o obj\Debug\src\main\Projectil.o obj\Debug\src\main\RequeteProcess.o obj\Debug\src\main\Rocket.o obj\Debug\src\main\divers.o obj\Debug\src\main\glfont2.o obj\Debug\src\menu\Controller.o obj\Debug\src\menu\MainMenuView.o obj\Debug\src\menu\OpenCentralisateurView.o obj\Debug\src\menu\OpenSceneASEView.o obj\Debug\src\menu\OpenSceneMapView.o obj\Debug\src\menu\OpenSceneView.o obj\Debug\src\menu\View.o obj\Debug\src\menu\Viewer.o obj\Debug\src\reseau\Client.o obj\Debug\src\reseau\Reseau.o obj\Debug\src\reseau\SPA.o obj\Debug\src\reseau\Server.o obj\Debug\src\reseau\a_virer.o obj\Debug\src\ressource\RessourcesLoader.o obj\Debug\src\son\DemonSons.o obj\Debug\src\son\ReqSon.o obj\Debug\src\son\Son.o obj\Debug\src\son\audio.o obj\Debug\src\spatial\FichierASE.o obj\Debug\src\spatial\IfstreamMap.o obj\Debug\src\spatial\Map.o
obj\Debug\src\spatial\MoteurParticules.o obj\Debug\src\spatial\Mouve.o obj\Debug\src\spatial\Particule.o obj\Debug\src\spatial\XmlVocabulaire.o obj\Debug\src\spatial\contact.o obj\Debug\src\spatial\geo\ChanTex.o obj\Debug\src\spatial\geo\Geo.o obj\Debug\src\spatial\geo\GeoMaker.o obj\Debug\src\spatial\geo\GeoObject.o obj\Debug\src\spatial\geo\MultiMaterialGeo.o obj\Debug\src\spatial\geo\SimpleGeo.o obj\Debug\src\spatial\geo\SimpleMaterialGeo.o obj\Debug\src\spatial\geo\TexVertexList.o obj\Debug\src\spatial\geo\TextureMaterialGeo.o obj\Debug\src\spatial\light\Light.o obj\Debug\src\spatial\light\LightMaker.o obj\Debug\src\spatial\light\LightOmni.o obj\Debug\src\spatial\light\LightTarget.o obj\Debug\src\spatial\materiau\Material.o obj\Debug\src\spatial\materiau\MaterialMaker.o obj\Debug\src\spatial\materiau\MaterialMulti.o obj\Debug\src\spatial\materiau\MaterialTexture.o obj\Debug\src\spatial\materiau\Textures.o obj\Debug\src\spatial\objet\Navette.o
obj\Debug\src\spatial\objet\Porte.o obj\Debug\src\util\Erreur.o obj\Debug\src\util\FindFolder.o obj\Debug\src\util\GenRef.o obj\Debug\src\util\Tableau.o obj\Debug\src\util\TableauIndex.o obj\Debug\src\util\Trace.o obj\Debug\src\util\TraceMethod.o obj\Debug\src\util\V3D.o obj\Debug\src\util\XmlHelper.o obj\Debug\src\util\mathFast.o obj\Debug\src\util\math_vectoriel.o obj\Debug\src\util\utils_SDL.o    -lmingw32 -lag_gui_static -lag_core_static -lwinmm -lfreetype -lSDLmain -lSDL -lSDL.dll -lopengl32 -lglu32 -lSDL_net -lSDL_image -lfmodvc -lpthreadGC2 -lmingwex


Libs\agar-1.3.4-recompile\lib/libag_gui_static.a(file_dlg.o): In function `fprintf':
C:/MinGW/include/stdio.h:246: undefined reference to `___mingw_vfprintf
'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 14 seconds)
1 errors, 0 warnings




________________________________
De : Keith Marshall <***@users.sourceforge.net>
À : mingw-***@lists.sourceforge.net
Envoyé le : Jeu 31 Décembre 2009, 19 h 29 min 38 s
Objet : Re: [Mingw-users] undefined reference with ___mingw_vfprintf
Post by JonY
I thought he was using msvc "cl" to compile and link, which needs
to be told to use libmingwex.a.
It would, IF the dependency on MinGW's enhanced printf() subsystem is
REALLY desired.  When building a library intended for use with other
compilers than MinGW, it may be a rash choice to introduce that
dependency; better IMO, to understand why the dependency arises in
the first place, and then make an informed choice on whether to keep
it, or to eliminate it.
Post by JonY
Apparently, this is not the case.
C:/MinGW/include/stdio.h:246: undefined reference to
`___mingw_vfprintf'
collect2: ld returned 1 exit status
The use of collect2 suggests a GNU tool chain, (and the reference in
question shows us that some compilation unit in the project was
built with compile time flags to explicitly map fprintf() to
__mingw_fprintf(), rather than to the default __msvcrt_fprintf()).
--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Keith Marshall
2010-01-01 15:35:20 UTC
Permalink
Post by JC
Here is the link command line generated by my IDE (CodeBlocks)
followed by the result of the command line. I wish it can help, I
don't see anything strange for me.
[...snip...]
No, I don't see anything obvious either; the `-lmingwex' at the end
should not be necessary, but it can't hurt.

To diagnose this further, we need to go back to basics. Please try
the following simple test case:--

$ cat testcase.c
#include <stdio.h>

int main()
{
long double a = 10.0, b = 50.0;
printf( "a = %Lf; b = %Lf; a * b = %Lf\n", a, b, a * b );
return 0;
}

First compile and run it, using only default compiler options; you
should see something like this:

$ mingw32-gcc -o testcase.exe testcase.c

$ ./testcase.exe
a = -0.000000; b = 0.000000; a * b = 0.000000

Clearly, not what you'd expect from the code, but here we are using
Microsoft's printf() implementation, which is unable to interpret
MinGW's 80-bit `long double' data type, so it is the appropriate
outcome. Now, compile and run it again, but this time compile with
the `-posix' option, (which is one way to activate MinGW's enhanced
printf() subsystem); this time you should see:

$ mingw32-gcc -posix -o testcase.exe testcase.c

$ ./testcase.exe
a = 10.000000; b = 50.000000; a * b = 500.000000

Let us know how you get on.
--
Regards,
Keith.
Keith Marshall
2009-12-31 14:50:15 UTC
Permalink
Post by JC
I have a problem an undefined reference with ___mingw_vfprintf. Do
somebody knows where it could come from please ?
You don't provide anywhere near enough information for us to be able
to say, but there are two or more issues here (see below).
What is the command which was run, to generate this? (The actual
command invoked *by* the makefile, or build script, as appropriate).
Post by JC
-------------- Build: Debug in jkt2010 ---------------
Linking console executable: bin\Debug\jkt2010.exe
Libs\agar-1.3.4-recompile\lib/libag_gui_static.a(file_dlg.o): In
function `fprintf': C:/MinGW/include/stdio.h:246: undefined
reference to `___mingw_vfprintf' collect2: ld returned 1 exit
status
Process terminated with status 1 (0 minutes, 2 seconds)
1 errors, 0 warnings
This was raised previously a couple of weeks ago, but I don't believe
it was ever adequately answered. There are at least two issues here:

1) Why is this symbol being referenced in the first place? Unless
you request MinGW's enhanced printf() support, either explicitly, or
implicitly by specifying a compilation standard which requires it,
(see _mingw.h in the system include directory), then this symbol
should not be referenced at all.

2) If you understand why it is required, and believe it correct that
it is, then you need to determine why the appropriate library is not
being included in the link; (this is why it is important for you to
show us the linking command). The missing symbol is defined in
libmingwex.a, from mingwrt version 3.15 onward, (and your stdio.h
*must* be from a conforming release for the reference to appear at
all); the issue is why is that library not searched, because it is
automatically included as a default system library, if you've
specified the linking command correctly, (using gcc or g++, as you
are supposed to, and *not* trying to invoke ld directly).
--
Regards,
Keith.
Tor Lillqvist
2010-01-01 17:44:05 UTC
Permalink
So this codebase contains its own re-implementation of fprintf (and
presumably other functions in the family)? I would say it is only to
be expected then that such code might be quite hard to build in
environments that differ even slightly from the "normal", or that have
evolved since last tested. Are you sure a Code Blocks build using
current MinGW of this code is even supposed to work?

--tml
JonY
2010-01-02 01:57:24 UTC
Permalink
Post by Tor Lillqvist
So this codebase contains its own re-implementation of fprintf (and
presumably other functions in the family)? I would say it is only to
be expected then that such code might be quite hard to build in
environments that differ even slightly from the "normal", or that have
evolved since last tested. Are you sure a Code Blocks build using
current MinGW of this code is even supposed to work?
--tml
Hi,

I think Code Blocks is picking up the new headers, but for some reason
using the older mingw libs.

Its possible OP has 2 MinGW install side-by-side, one of them bundled
with Code Blocks, hence a version mismatch of sorts.

Loading...