{"action":"created","issue":{"url":"https://api.github.com/repos/rampantpixels/foundation_lib/issues/13","labels_url":"https://api.github.com/repos/rampantpixels/foundation_lib/issues/13/labels{/name}","comments_url":"https://api.github.com/repos/rampantpixels/foundation_lib/issues/13/comments","events_url":"https://api.github.com/repos/rampantpixels/foundation_lib/issues/13/events","html_url":"https://github.com/rampantpixels/foundation_lib/issues/13","id":125626588,"number":13,"title":"Problems building foundation_lib using MSYS2 (MinGW)","user":{"login":"gschmottlach","id":1666389,"avatar_url":"https://avatars.githubusercontent.com/u/1666389?v=3","gravatar_id":"","url":"https://api.github.com/users/gschmottlach","html_url":"https://github.com/gschmottlach","followers_url":"https://api.github.com/users/gschmottlach/followers","following_url":"https://api.github.com/users/gschmottlach/following{/other_user}","gists_url":"https://api.github.com/users/gschmottlach/gists{/gist_id}","starred_url":"https://api.github.com/users/gschmottlach/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gschmottlach/subscriptions","organizations_url":"https://api.github.com/users/gschmottlach/orgs","repos_url":"https://api.github.com/users/gschmottlach/repos","events_url":"https://api.github.com/users/gschmottlach/events{/privacy}","received_events_url":"https://api.github.com/users/gschmottlach/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2016-01-08T14:56:20Z","updated_at":"2016-01-12T22:13:09Z","closed_at":null,"body":"My workflow typically involves building Windows libraries  from a Linux host using MSYS2 and a cross GCC tool-chain (e.g. cross compile on Linux for a Windows target). Microsoft's Visual Studio is not available.\r\n\r\nFirst Question: Has anyone tried this work-flow or alternate Microsoft compiler?\r\n\r\nI put together a GNU makefile to compile foundation_lib directly because in addition to the static archive (libfoundation.a) I also needed a shared library variant (libfoundation.so). On a Linux host (for a Linux target) this works fine - both static and shared libraries are produced using the makefile.\r\n\r\nWhen building the Windows variant of foundation_lib I've encountered the following problem. It appears (somehow) that any file I build within foundation_lib has extra symbols defined (T) in the object file even though they're never referenced in that file. This seems to occur whenever #include \\<foundation/platform.h\\> is included in the source file.  Here's a simple example function:\r\n\r\nFile: test.c\r\n```\r\n#include <string.h>\r\n#include <stdio.h>\r\n#include <math.h>\r\n\r\nvoid test_it(char* buf)\r\n{\r\n        strcpy(buf, \"hello\");\r\n        sprintf(buf, \"%f\", fabs(5.0));\r\n        return;\r\n}\r\n```\r\n\r\nRunning ```nm``` on the resulting test.o I see the following:\r\n\r\n```\r\n0000000000000000 b .bss\r\n0000000000000000 d .data\r\n0000000000000000 N .debug_abbrev\r\n0000000000000000 N .debug_aranges\r\n0000000000000000 N .debug_frame\r\n0000000000000000 N .debug_info\r\n0000000000000000 N .debug_line\r\n0000000000000000 N .debug_loc\r\n0000000000000000 p .pdata\r\n0000000000000000 r .rdata\r\n0000000000000000 r .rdata$zzz\r\n0000000000000000 t .text\r\n0000000000000000 r .xdata\r\n                 U sprintf\r\n0000000000000000 T test_it\r\n```\r\n\r\nIf I add **one** line to the file to include \\<foundation/platform.h\\> . . .\r\n```\r\n#include <foundation/platform.h>\r\n#include <string.h>\r\n#include <stdio.h>\r\n#include <math.h>\r\n\r\nvoid test_it(char* buf)\r\n{\r\n        strcpy(buf, \"hello\");\r\n        sprintf(buf, \"%f\", fabs(5.0));\r\n        return;\r\n}\r\n```\r\n\r\nand recompile and execute ```nm```  again to see the symbols I see . . .\r\n```\r\n0000000000000000 b .bss\r\n0000000000000000 d .data\r\n0000000000000000 N .debug_abbrev\r\n0000000000000000 N .debug_aranges\r\n0000000000000000 N .debug_frame\r\n0000000000000000 N .debug_info\r\n0000000000000000 N .debug_line\r\n0000000000000000 N .debug_loc\r\n0000000000000000 N .debug_str\r\n0000000000000000 p .pdata\r\n0000000000000000 r .rdata\r\n0000000000000000 r .rdata$zzz\r\n0000000000000000 t .text\r\n0000000000000000 r .xdata\r\n0000000000000030 T _Exit\r\n00000000000000e0 T __fpclassify\r\n0000000000000140 T __fpclassifyf\r\n00000000000000d0 T __fpclassifyl\r\n                 U __imp__stricmp\r\n                 U __imp__strnicmp\r\n0000000000000180 T __isnan\r\n00000000000001b0 T __isnanf\r\n00000000000001d0 T __isnanl\r\n                 U __mingw_vsprintf\r\n00000000000001f0 T __signbit\r\n0000000000000200 T __signbitf\r\n0000000000000210 T __signbitl\r\n                 U _exit\r\n0000000000000330 T copysign\r\n0000000000000380 T copysignf\r\n                 U cosh\r\n0000000000000250 T coshf\r\n                 U exp\r\n0000000000000290 T expf\r\n00000000000000c0 T fabs\r\n00000000000000a0 T fabsf\r\n00000000000000b0 T fabsl\r\n                 U frexp\r\n00000000000002b0 T frexpf\r\n                 U hypot\r\n00000000000002f0 T hypotf\r\n0000000000000080 T imaxabs\r\n                 U ldexp\r\n00000000000002d0 T ldexpf\r\n0000000000000040 T llabs\r\n                 U pow\r\n0000000000000310 T powf\r\n                 U sinh\r\n0000000000000230 T sinhf\r\n0000000000000000 t sprintf.constprop.0\r\n0000000000000070 T strcasecmp\r\n0000000000000060 T strncasecmp\r\n                 U tanh\r\n0000000000000270 T tanhf\r\n00000000000003b0 T test_it\r\n```\r\n\r\nWhere did all these (unreferenced) functions like frexpf() or sinhf() come from??? When I build the entire Foundation library for Windows and try to link a shared library (DLL) the linker complains about multiple definitions since each *.o file contains these duplicate symbols. The command line I'm using to compile this example is:\r\n\r\n```\r\nx86_64-w64-mingw32.static-gcc  -c -Wall -Werror -Wextra -Wpedantic -std=c11 -Wno-unknown-pragmas -Wno-unused-parameter -Wno-format -Wno-unused-function -Wno-pedantic -Wno-strict-aliasing -funit-at-a-time -fstrict-aliasing -fno-math-errno -ffinite-math-only -funsafe-math-optimizations -fno-trapping-math -ffast-math -g -DFOUNDATION_COMPILE=1 -DBUILD_DEPLOY=1 -funroll-loops -O4 -m64 -I/home/swdev/project -o test.o  test.c\r\n```\r\nI am also attaching a file that contains the settings of all the macro definitions defined in the environment as well as in foundation/platform.h. This environment is derived by executing:\r\n\r\n```\r\necho \"#include  <foundation/platform.h>\" | x86_64-w64-mingw32.static-gcc -I/home/swdev/project -E -dM - > env.txt\r\n```\r\n\r\nI've also run into some issues with MinGW where functions like ```_ftime_s()``` are not defined (had to fall back to using ```_ftime64()```) and ```localtime_s()``` and ```gmtime_s()``` are not available either. Finally, there is also an issue with crash.c and specifically ```_crash_dump_file_buffer``` and ```_crash_dump_file```. Apparently these aren't defined anywhere in the library either.  Where are these defined in Windows?\r\n\r\nAny help and/or suggestions would be very much appreciated. I'd love to be able to use this library but the Windows support under MinGW seems to be an issue at this time.\r\n\r\nThanks for your time and patience . . .\r\n\r\n[env.txt](https://github.com/rampantpixels/foundation_lib/files/82809/env.txt)\r\n"},"comment":{"url":"https://api.github.com/repos/rampantpixels/foundation_lib/issues/comments/171076809","html_url":"https://github.com/rampantpixels/foundation_lib/issues/13#issuecomment-171076809","issue_url":"https://api.github.com/repos/rampantpixels/foundation_lib/issues/13","id":171076809,"user":{"login":"MJansson","id":3316562,"avatar_url":"https://avatars.githubusercontent.com/u/3316562?v=3","gravatar_id":"","url":"https://api.github.com/users/MJansson","html_url":"https://github.com/MJansson","followers_url":"https://api.github.com/users/MJansson/followers","following_url":"https://api.github.com/users/MJansson/following{/other_user}","gists_url":"https://api.github.com/users/MJansson/gists{/gist_id}","starred_url":"https://api.github.com/users/MJansson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MJansson/subscriptions","organizations_url":"https://api.github.com/users/MJansson/orgs","repos_url":"https://api.github.com/users/MJansson/repos","events_url":"https://api.github.com/users/MJansson/events{/privacy}","received_events_url":"https://api.github.com/users/MJansson/received_events","type":"User","site_admin":false},"created_at":"2016-01-12T22:13:08Z","updated_at":"2016-01-12T22:13:08Z","body":"Building as a shared library has not been a goal, but if there is interest in it, why not? :)\r\n\r\nThe problem is that the library aims to abstract away all the different entry points for different platforms and application types. I guess the most logical thing in a shared library would be to simply not wrap any entry points. I'll look into it."}}