| Код |
extern "C" { |
2. Мало кто захочет лезть на какой-то файлопомойкуфайлообменник и скачивать оттуда 6 МБ...
2.1. Выкинь из архива лишнее
2.2. Залей его прямо сюда (прикрепи к теме)
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > ошибки компиляции консоли с++ и zlib 1.1.3 |
| Автор: ohos 21.1.2012, 14:50 |
| Привет, скачал в интернете исходники zlib 1.1.3 (знаю, что последняя версия гораздо больше, но мне нужна именно эта) и в microsoft visual studio 2010 пытаюсь скомпилировать простенькое консольное с++ приложение, все файлы zlib включил в проект (архив со всем проектом http://www.fayloobmennik.net/1448112), но при компиляции лезет ряд ошибок, решение которых мне не удается найти в интернете: Ошибка 1 error LNK2019: ссылка на неразрешенный внешний символ _deflate в функции "int __cdecl def(struct _iobuf *,struct _iobuf *,int)" (?def@@YAHPAU_iobuf@@0H@Z) Ошибка 2 error LNK2019: ссылка на неразрешенный внешний символ _deflateEnd в функции "int __cdecl def(struct _iobuf *,struct _iobuf *,int)" (?def@@YAHPAU_iobuf@@0H@Z) Ошибка 3 error LNK2019: ссылка на неразрешенный внешний символ _deflateInit_ в функции "int __cdecl def(struct _iobuf *,struct _iobuf *,int)" (?def@@YAHPAU_iobuf@@0H@Z) Ошибка 4 error LNK2019: ссылка на неразрешенный внешний символ _inflate в функции "int __cdecl inf(struct _iobuf *,struct _iobuf *)" (?inf@@YAHPAU_iobuf@@0@Z) Ошибка 5 error LNK2019: ссылка на неразрешенный внешний символ _inflateEnd в функции "int __cdecl inf(struct _iobuf *,struct _iobuf *)" (?inf@@YAHPAU_iobuf@@0@Z) Ошибка 6 error LNK2019: ссылка на неразрешенный внешний символ _inflateInit_ в функции "int __cdecl inf(struct _iobuf *,struct _iobuf *)" (?inf@@YAHPAU_iobuf@@0@Z) Ошибка 7 error LNK1120: 6 неразрешенных внешних элементов Прошу помочь с компиляцией. |
| Автор: borisbn 21.1.2012, 16:21 | ||
1. Похоже проблема в том, что ты включаешь Си-шный h-ник в c++-ный cpp-шник. Попробуй так
2. Мало кто захочет лезть на какой-то файлопомойкуфайлообменник и скачивать оттуда 6 МБ... 2.1. Выкинь из архива лишнее 2.2. Залей его прямо сюда (прикрепи к теме) |
| Автор: ohos 21.1.2012, 18:20 |
| благодарю за совет, попробовал, не помогло, исходник действительно должен быть С-ишный, но в 2010 студии почему-то нету С языка при создании проекта я бы прикрепил к сообщению архив с проектом, но он просто не влезает, как определить, что лишнее? |
| Автор: tzirechnoy 21.1.2012, 20:23 |
| Да выкинь ты эту вижуал студию, только мозги оно конопатить способно. Hint: предыдущий оратор привёл пример кода, который надо писать в твоём файле. |
| Автор: ohos 21.1.2012, 20:50 | ||
я вписал
но все равно не помогло, если не студией, чем тогда скопмилировать? |
| Автор: tzirechnoy 21.1.2012, 21:41 |
| Хм. Я только сейчас понял смысл сообщений. Явно забыто -lz при вызове компилятора. |
| Автор: ohos 21.1.2012, 23:01 | ||
т.е. мне нужно запустить саму студию с таким параметром или указать его в самом коде? |
| Автор: volatile 21.1.2012, 23:45 | ||
ohos, врядли это поможет. я собирал как-то проект содержащий zlib на студии, проблем не помню вообще никаких. (правда, с другой версией zlib'а) Скорей всего вы просто забыли в проект добавить библиотеку. Напишите где-нибудь в *.cpp следующую фразу #pragma comment(lib,"zlibwapi.lib") ну и zlibwapi.lib бросьте туда, где ее сможет найти линкер. |
| Автор: ohos 21.1.2012, 23:48 | ||
с другого форума
запустил, работает, то что я не шарю совсем в с++ даже не отрицаю) |
| Автор: mes 22.1.2012, 00:03 | ||||
 я так понимаю такое решение вызвано словом
тогда небольшая поправка : неразрешенный это не запрещенный, а нерешенный  |
| Автор: vol4ek 22.1.2012, 00:30 | ||||
цыц
|
| Автор: tzirechnoy 22.1.2012, 07:59 | ||
Да-да, я именно об этом. Вместо стандартного с основния C метода предлагается насиловать исходник странными прагмами. Студию в морг, возьмите mingw+msys хотя бы. |
| Автор: borisbn 22.1.2012, 20:52 | ||||||
Подскажите тогда IDE, которая сама добавляет в проект недостающие Си-шники или lib-ины... В студии (в отличие от других) есть 2 возможности включить lib-ину в проект: 1)
2) в опциях проекта добавить путь к lib-файлам и имя включаемой lib-ины Короче, нечо на студию пенять, если ручки кривые |
| Автор: vol4ek 22.1.2012, 21:42 | ||
золотые слова |
| Автор: volatile 23.1.2012, 00:57 | ||
Так никто не заставляет насиловать исходник Можете вставлять библотеки в проект руками, также как это делаете в mingw+msys  То что в студии есть такая возможность, (помимо того что есть в mingw) это что недостаток?. Буст например активно юзает эту возможность (и довольно по-делу!), посмотрите например boost\config\auto_link.hpp Вобще пнуть студию лишний раз это какбе круто. (не важно по-делу, ли нет) Иногда до смешного доходит. Плохо - уже потому-что есть такая возможность.  |
| Автор: ohos 24.1.2012, 23:28 | ||||
| скажу честно, этот zlib мой первый опыт с c++ вообще) поэтому я выбирал студию мягких как инструмент, который будет указывать мне на тупые ошибки с достаточным описанием, чтобы решить её, по крайней мере я на это надеялся но у меня с zlib'ом остался один весьма неразрешенный вопрос - компилироваться-то он компилируется, да вот не работает как надо, вопросы по проблемам в работе и последний рабочий исходник в этой теме выложить или создать отдельную тему? на всякий случай вот сами проблемы: 1. при запаковке файла через указание параметров только в deflateinit (уровень сжатия) пишется статус "зашибись, все okay", но когда открываю файлик сжатый тем же notepad++, то в конце файла отчетливо вижу мусорные символы (один и тот же символ, русская буква Н, или в Hex это CD), количество которых зависит напрямую от директивы
если сделать chunk 1, то количество мусорных символов явно меньше, всего 2 или 3, как следствие такой файл потом не распаковывается 2. пытался распаковать файл, от которого у меня есть: исходный сжатый и распакованный (для сверки), распаковка не удалась... точнее в первый раз как-то распаковалось больше 80%, не было лишь последних двух строк текста содержащих
изначально распаковывал со стандартными параметрами в inflateinit, потом использовал inflateinit2 и перебрал все допустимые windowBits (диапазоны от -15 до -8 и от 8 до 15), распаковка так же не удалась, хуже того, больше не удается сделать распаковку хотя бы 80% файла, что-то явно случилось за это время... p.s. по рекомендации borisbn почистил от мусора (после чистки проверил, запускалось, значит лишнего не удалил) и приложил те 400 кб исходного проекта к сообщению, еще в архиве исходный сжатый файл comp_00020.lua и его распакованная версия decomp_orig_00020.lua |
| Автор: volatile 25.1.2012, 13:50 |
| У вас проблемы не со студией, и даже не с zlib Вы просто элементарно не правильно работаете с файлами. Добавлено через 10 минут и 54 секунды да, чуть не забыл, в исходниках поменяйте размещение файлов с L:\ на С:\ (не хотел загрязнять свой С:\) |
| Автор: tzirechnoy 25.1.2012, 18:36 | ||
Где возможность? С основания C эта возможность была через строку -lz в вызове компилятора. Куда её вписывать этой студии? Не надо мне разсказывать про 4-х уровневые менюшки, к тому жэ разные на китайской и французской версии. Это -- другое. |
| Автор: volatile 25.1.2012, 23:19 | ||
вы это о чем? о каком основании С:  tzirechnoy, в студии можно вообще работать без IDE, с голимой комм.строкой Как я понял вы это считаете пределом совершенства? дальнейший спор неуместен. Не нравиться студия, ради бога. мне это как-то по-барабану. |
| Автор: ohos 26.1.2012, 01:00 | ||
| volatile, благодарю вас, я посмотрел отличия, если я правильно понял, то они лишь в отсутствии знака + в функциях fopen, запаковка исходного файла и распаковка работает, но после я пытался распаковать один странный файл упакованный вроде бы zlib 1.1.3 с заголовком кратным 31, во время распаковки возникает ошибка и я решил более точно определить, где именно в inflate функции из файла inflate.c это происходит путем вывода сообщений в консоль, но студия ругается на использование там PRINTF или fputs, как правильно их там использовать? например ошибка: ссылка на неразрешенный внешний символ _PRINTF в функции _inflate если вставить в inflate.c функцию
|
| Автор: volatile 26.1.2012, 01:28 | ||||
+ не причем. у вас файл после записи в него не закрывался. И позиция указывала на конец. А вы пытались из него читать. в итоге ...
В С/С++ имена функций регистрозависимы. функции PRINTF не существует... ohos, возможно вам рано браться за такие проекты? Может стоит сначала почитать учебники. Вы не знаете самых основ. |
| Автор: ohos 26.1.2012, 13:02 |
volatile, согласен, рано по уровню знаний в c++, но к сожалению не по необходимости, к тому же учиться никогда не поздно, а учиться на нужном и дельном примере еще и интересно  я попробую вечером набрать в правильном регистре функцию, просто слишком привык в некоторых языках к независимости |
| Автор: ohos 27.1.2012, 01:43 | ||||
| volatile, прошу прощения, но если у вас еще есть желание помочь в решении вопросов, то они уже появились printf сработало, нужно было действительно писать маленькими буквами и я добавил вывод сообщений в функции inflate и затем inflate_blocks, чтобы понять, где "разница" и как её избежать при распаковке "странного" файла, в отличие от того, который был пожат этим же консольным приложением, в результате я нашел то место "различия", оно оказалось в функции inflate_blocks, точнее говоря в куске её кода
тут нормальный файл уходит в мод DRY, а исследуемый мной "странный" в TYPE (на новый круг распаковки, чего быть вроде не должно, потому-что все данные на распаковку умещаются в один размер CHUNK), но в данном куске я напрочь не понимаю, что означает проверка (!s->last) и как она происходит, найти в интернете оказалось довольно сложно, так как я пытался искать по ->, а все поисковые системы воспринимают знак минуса как логический оператор "не", а не текст, символ > правда тоже похоже для них не является просто текстом либо вообще заблокирован для поиска, но теоретически я догадываюсь, что s является переменной из объявления
а last проверка, стоит ли указатель в конце файла или нет, но это лишь "теория". так как я не знаю и не могу найти ответ из-за слишком продвинутых поисковых систем архив со своей версией показывающей шаги по распаковке, оба файла ("странный" и запакованный этим же консольным приложением), а так же скрин с выявленными различиями - прикладываю и прошу помочь разобраться с распаковкой "странного" файла или хотя бы дать подсказку о той затычной проверке) хочу отметить еще, что оба запакованных файла имеют заголовок (2 байта) кратные 31, если бы "странный" был сломан совсем, то он бы тогда имел наверняка битый заголовок и то приложение, которое им пользуется не смогло бы читать файл, а оно использует как раз zlib.dll версии 1.1.3 (MD5 этой dll совпадает с теми, что я качал из интернета, значит zlib используется не измененный), а сейчас он всего лишь больше того, который у нормального (странный - 789C, нормальный - 7801) еще хочу заметить, что у zlib при распаковке есть возможность указывать настройки в лице windowBits, но я уже пробовал его изменять, перебирал все диапазоны (от -15 до -8 и от 8 до 15), не помогло... |
| Автор: volatile 27.1.2012, 23:54 |
| ohos, как я понял вы хотите распаковать неизвестно откуда взятый файл, и он у вас не распаковывается. А с чего вы взяли что он например не зашифрован, или что к нему не прибавили какие-то служебные байты в начале (например название фала, или размер)? Программа свои функции выполняет нормльно. А то что вы пытаетесь сделать - уже попытка угадать в лотерею, методом тыка. Нужно смотреть исходники той программы, которая и создала этот файл. |
| Автор: ohos 28.1.2012, 00:17 |
| volatile, откуда взят файл, известно, брал правда не я сам, гарантии отсутствия шифрования конечно же нет, но я уверен, что шифровать его еще поверх было бы глупо, потому-что он и так был в "самопальном" архиве, любой желающий его бы и так не смог открыть, к тому же шифрование сказалось бы на производительности, а это при сжатии и перечитывании файла при любом обращении к нему по моему недопустимая роскошь к тому же одно время удалось пообщаться с человеком, который его из того архива самопального вытащил, он то и дал прогу для распаковки архива, говорил что не очень сложно было разобраться, но ни исходников того распаковщика ни объяснений не дал и контакт с ним потом потерялся, возможно он просто сильно забил на все это я решил не идти сразу по пути реверс инжиниринга, так как в нем я еще больше не шарю, хотя когда-то пробовал на креклабе, решил проверить файл на возможность распаковки стандартным zlib, т.к. приложение использующее тот самопальный архив использует стандартную zlib.dll версии 1.1.3 то, что эта версия работает корректно сама по себе, я уже убедился и за это крайне благодарен вам, но необходимость разобраться что именно с тем странным файлом все же есть, при его просмотре в WinHex я заметил одну весьма странную осоденность, у него в конце идет много нулей и кусочек текста, не исключаю, что он тут просто лишний, но пока не пробывал перебирать распаковку с отрезанием последних байт файлов, хотя попробую и это на всякий случай |
| Автор: volatile 28.1.2012, 00:45 |
| ohos, хорошо. Скинтье отдельно этот файл. Будет время я посмотрю. Если есть распокованый он-же, то тоже скинтье Естественно обещать что угадаю алгортм не буду. |
| Автор: ohos 29.1.2012, 14:27 |
| я проверил все старые файлы исходные, что были и нашел, файл который я пытался распаковать был неправильным, т.к. по ошибке был извлечен тем человеком как не сжатый, он потом присылал мне еще один, который по сути тоже сжат, но извлечен правильно, архив с тремя луа файлами во вложении orig_source_00020.lua - оригинальный файл извлеченных из странного архива orig_comp_00020.lua - сжатый вариант файла из странного архива console_comp_00020.lua - сжатый вариант оригинального файла этой консолью, проблемы в работе которой обсуждались в данный момент странна лишь одна вещь, файл извлекается, но консольное приложение пишет ошибку, я попробую еще раз перебрать все windowBits, так как в прошлый раз делал это с криво извлеченным из самопального архива) |
| Автор: ohos 30.1.2012, 00:45 |
я перебрал все варианты сжатия, затем стал искать файлы имеющие такой же заголовок 2 байта и сравнивать их на соответствие байт "странному" файлу, в итоге было найдено порядка 6-8 возможных опций при которых из 164 байтов "странного" файла совпадают аж 159!  вот на всякий случай архив со всеми вариантами распакованными + точно тот, где совпадает 159 байт из 164 comp_00020_lvl5_winbits15_memlv2_strategy0.lua параметры сжатия соответственно level 15, method 8 (константа) ,windowBits 15, memLevel 2, strategy 0 уважаемый volatile, полагаю теперь загадка "странного" файла не настолько тяжелая и вы мне поможете её разгадать? я пока что попробую поискать другие файлы из странного архива, для сравнения и проверки |
| Автор: volatile 30.1.2012, 01:09 | ||||
Скорей всего это просто поврежденный файл, тем более что
В общем пройдя токое количество рук, файлу трудно остаться не поврежденным ohos, распаковщик должен расжать файл, независимо от способа запаковки. Если пишет ошибку, значит файл поврежден. либо записан другим упаковщиком/другой версией. |
