За выходные (2 дня бился головой о клавиатуру) решение нашлось... вопрос в его адекватности.

Есть примитивный код на ВинАПИ, создающий иконку в трее, разворачивающий маленькое меню по щелчку правой кнопкой мыши и открывающее OpenFile диалог по выбору одного из пунктов. Приводить код не буду, он прост до неприличия, по сути - каркас для будущего приложения.

Решился я (как джавный программист) использовать в качестве IDE незабвенный Eclipse, присобачив у нему MinGW 3.4.2. Задача решаемая, скачал cdt3.1, установил, настроил согласно многочисленным мануалам. Кстати, интересная штука... сначала пытался установить cdt4.0.1, но он по непонятным причинам затребовал установленный плагин org.eclipse.core.filesystem_1.0.0 и без него отказывался ставиться. То, что плагин был уже установлен, его не интересовало... Ну да позже разберусь.

Дальше штука вот такая - компилился файл в объектный без приключений, но при сборке линкер выдавал Undefined Reference to GetOpenFileNameA@4. Хидер (commdlg) был подключен правильно, пути к библиотеке (libcomdlg32.a) тоже были прописаны, значит, где-то чего-то я недоглядел...

Несколько часов тыканья по различным настройкам эклипса привели к тому, что я решил наплевать на Managed C++ Make и скомпилить просто из командной строки, чтобы сориентироваться в ситуации. Однако и там линковка давала тот же результат! Не помогали ни ключ -l"путь к библиотеке", ни ключ -L"путь к библиотекам", ни #pragma comment(lib, "libcomdlg32.a") в коде. Причём g++ -print-file-name=libcomdlg32.a показывал, что библиотека есть и все пути прописаны правильно.

В результате помог ход конём. Какая среда обычно работает с MinGW? Правильно, Dev-Cpp. Сборка из под него выдавала ту же ненавистную ошибку, однако на этот счёт гугл имел своё мнение. Так и сказал - "в настройках проекта пропиши линкеру -lбиблиотека". Не сказать, чтобы соврал... именно в таком виде работать отказался. Но без -l и с указанием полного пути вдруг всё собралось!

И среди многочисленных ключей в недрах make файла, созданного это IDE, сверкнуло -mwindows...

Как итог моих терзаний, в эклипсе правый клик по папке проекта -> Properties -> C/C++ Build -> Tool Settings -> GCC C++ Linker -> Command и вписывание строчки mingw32-g++ -mwindows дало ожидаемый результат. Всё собралось!

Как оказалось, проблема не в эклипсе, а в ловкости обращения с MinGW 3.4.2... А теперь внимание, вопрос. 

Почему???? Почему именно так??? Это же и так компилятор под виндовс, зачем ему ещё эту строчку указывать? Почему он прекрасно разобрался с подключением функций из shellapi, но сломался на OpenDialog'е? Постфактум, поиск по всему С++ подразделу форума на строчку -mwindows не дал ни одного совпадения! Этот ключ ни разу не упоминался... и гугл молчит! Я в дауне.

Вот пример кода, который требует обязательного указания ключа -mwindows.

Компилится с командной строки так: g++ -mwindows -o Open.exe Open.cpp
Если опустить ключ -mwindows, ругается на undefined reference to GetOpenFileNameA@4.
Кто может пролить свет на загадку? Или это просто у меня кривая версия MinGW?

В MSDN-е при GetOpenFileName нету [Base], а, например, при CreateNamedPipe - [Base] есть. Может, в этом заморочка?
А вот что нашёл Рамблер (Гуголь в полном пролёте, я в шоке!!!): тыц
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
В данном примере мы создаем hello.exe из hello.o, флаг -mwindows необходим, чтобы создать Windows-приложение, а не консольное. Этим мы говорим компилятору, что нужно подключить соответствующие библиотеки. Чтобы получить консольный экран наряду со стандартным приложением Windows, добавьте -mconsole флаг так же как -mwindows.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
А так же (опять Рамблер): тыц_2


Это сообщение отредактировал(а) EnergoHokum - 6.11.2007, 09:52

1, 2.

Просто, видимо, кто-то гуглём пользоваться не умеет...

Ага, ну правильно, гугл минус перед словом воспринимает как директиву, что это слово находить не надо   

Ок, всем спасибо, проблему подсветили с нужной стороны. Хотя я всё равно не понимаю, почему 1) нельзя просто прилинковать функции из нужных библиотек без лишних ключей, и 2) почему функции для работы с треем (явно виндовские) прекрасно линкуются безо всяких подсказок.

Добавлено через 2 минуты и 9 секунд
Ах, ну да, ты наверное писал

Библиотеки должны указываться после модулей/объектников.

archimed7592, маг и волшебник! Ещё такой вопрос: Почему требуется писать -lcomdlg32, если в папке либ файл хранится как libcomdlg32? Префикс "lib" проглатывается автоматически? Это из за него все косяки, оказывается, и Эклипс заработал правильно!

В папке он хранится вообще как libcomdlg32.a .
Ну так устроен gcc - он автоматом добавляет lib спереди и .a/.so(.dll для windows) в конце.

Добавлено через 48 секунд
К слову -mwindows тебе всё равно понадобится, ибо у тебя WinMain, а не main.

У меня была такая же проблема, только с FOX-toolkit. При сборке MinGW-шный g++ выдавал кучу ошибок намекая на то что не подключена какая то библиотека. Я потратил пару часов на подбор библиотек методом тыка В итоге все решилось как раз вот этой опцией, которую я тоже увидел в Makefile тестовых примеров

Ну, у тебя в примере только что всё собралось без изъянов, а дальше посмотрим. Правда как подумаю, что мне надо будет читать JPEG и PNG средствами WinAPI, сразу вешаться охота, а MFC я презираю (предвзято, надо отметить). Вроде Qt работает с ними на высоком уровне, но это тема для другой беседы.

Ещё можно обратить внимание на libpng, libjpeg.

1. в WinAPI нет средств для чтения JPEG и PNG
2. в MFC нет средств для чтения JPEG и PNG

нет наврал нагло, есть, ведь раньше даже работал - сорри.  
  

еще достаточно много в сети оберток над ними, cximage например.

Это сообщение отредактировал(а) zkv - 6.11.2007, 15:30

Получается что да, не умеет (знак огорчения). И всё таки, почему в МСДН-е при GetOpenFileName нету [Base], и вообще написано, что эта функция из WinMobile-вского SDK?

Потому что это пишется только рядом с ф-циями из kernel32.dll.



Наверное потому, что кое-кто не только гуглём пользоваться не умеет, но и MSDN.

Вот поэтому и охота вешаться    Читать сырые байты и обрабатывать    Спасибо archimed7592 за подсказку про библиотеки, сегодня начну ковыряться.

Shaggie, соврал я нагло (перемкнуло что-то...), см. выше. 
Работать неудобно, есть какие-то ограничения. 
Плюс еще можно gdi+ использовать, но нужно обеспечить его наличие на машине клиента.